W3C home > Mailing lists > Public > public-sws-ig@w3.org > September 2004

Re: A bunch of OWL-S difficulties

From: Daniel Elenius <daele@ida.liu.se>
Date: Tue, 21 Sep 2004 10:13:57 +0200
Message-ID: <414FE2C5.4030407@ida.liu.se>
To: public-sws-ig@w3.org

David Martin wrote:

>> 5) Split+Join vs Unordered
>> What is the difference between these two control constructs? Can I 
>> get an example to show the difference?
> From the technical overview, it appears to me that there's only one 
> difference: split+join indicates *concurrent* execution of a group of 
> activities, whereas unordered is non-committal on that point.  That 
> is, unordered is "looser", in that it could allow for either a 
> sequential or a concurrent execution (or perhaps some arbitrary 
> combination of the 2 approaches).  (Thus, informally, one could think 
> of the set of unordered executions as a superset of the set of 
> split+join executions.)
> As to how often anyone would care about this distinction, or if it 
> should be retained, that's a separate matter I guess.  Comments are 
> welcome on this question.
> Regards,
> David

Wouldn't a concurrent execution also include sequential execution as an
extreme case? If you execute things concurrently on a  single-cpu
computer, you switch back and forth, and it could be the case that one
process completes before the other one starts. The concurrency semantics
are simply non-commital on this point. At least in the OS case. And I
don't see why the case with distributed processes should be any
different. For example, if a composite process has a Split+Join with
processes A and B, would the user be doing a mistake if he did not
create a new thread and started both concurrently? I don't think so, I
think he should be allowed to execute A, wait for the return values,
then execute B, if he prefers. Separating the two cases seems to go into
implementation issues rather than process semantics.

Just my two cents of course ;)

Received on Tuesday, 21 September 2004 08:14:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:46 UTC