Re: Unordered construct

On Oct 11, 2004, at 11:57 PM, Evren Sirin wrote:
[snip]
> As we discussed, this is, in fact, not true of SHOP. SHOP does not 
> allow concurrent execution of operators, but does permit interleaving 
> operators from different methods.
>>
>> The rejoiner is that Split+Join allows this! Just don't parallelize 
>> the atomics. To this I say, Ugh.
>>
>> By this logic, we should kill unordered. In fact, that's my proposal, 
>> kill unordered. If you can't handle concurrency, go ahead,  don't 
>> handle it. Split+Join doesn't *require* concurrency, it just allows 
>> it.
>
> Yes, but it seems that sometimes you want to *forbid* concurrency (or 
> even interleaving) but do not want to impose any ordering. Naveen's 
> Unordered example was such a case and that is what started the 
> discussion about revising the definition of Unordered.

This is no riposte. Sometimes I want to do a *lot* of things. Either we 
should adequately parameterize Unordered (as we discussed, with an 
extra property, or maybe the composite processes performs, e.g., 
interleavableWith), or we should bag it for now.

Given that there was already a complaint about it being non-concurrent, 
it seems like fixing in one to cover a case which isn't even 
necessarily the most common current case (*requiring* non-interleaved 
composite processes? why?)

>> (I kinda like it. Prune, folks, prune!)
>>
>>> We still believe that both interpretations of Unordered are useful 
>>> but unless there are objections (though I know Bijan has :) the 
>>> definition of Unordered will be changed in accordance to the second 
>>> interpretation.
>>
>>
>> Evren and I discussed some ways to contrain Split+Join (or an 
>> unordered that allowed interleving). He thinks it's easy, so I'll 
>> leave it to him to explicate. I just died on the lack of daml:item.
>
>
> Yes, we discussed several different ways to define these control 
> constructs. The idea was to use temporal constraints to specify how 
> subcomponents occur with respect to each other, e.g. say that these 
> subcomponents can or cannot occur in overlapping intervals. This 
> seemed easy since Process class was defined to be subclass of Interval 
> class from time ontology (which I now realize is not the case in 1.1 
> anymore). But then it turned out that specifying these restrictions is 
> not that easy, especially when you consider that each subcomponent may 
> have other subcomponents. I don't anymore think it is easy :)

Heh. It *should* be easy :)

> There is of course the obvious solution: Defining new constructs for 
> different kind of interpretations so we would have Spit+Join, 
> Interleaving Unordered and non-interleaving Unordered. (Don't delete, 
> add more :)

Great! I'm *so* glad you volunteered.

Piffle. Where's Austin when you need him!

I'd suggest just cutting it, with perhaps a little explanation, 
including a discussion of the permissibily of non-concurrent execution 
of split-join. You could always define more restrictive variants 
(either as we discussed or by fiat).

Cutting split-join eases the burden on implementors, as they're free to 
implement it as best they can, and anyone relying on more is properly 
screwed.

Cheers,
Bijan Parsia.

Received on Tuesday, 12 October 2004 07:06:33 UTC