Re: A bunch of OWL-S difficulties

> [Daniel Elenius]
> 
> 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.

You're right: it's virtually impossible to _force_ two composite
processes to execute concurrently, because the phrase "truly
concurrent," while meaningful for atomic processes, is difficult to
apply to groups of atomic processes.  (Would it mean that at least one
pair of atomic processes executed over exactly the same interval?)

However, it's comparatively easy to require two processes _not_ to be
truly concurrent.  Just stipulate that for any two atomic subprocesses
A1 and A2 belonging to P1 and P2, either A1 precedes A2 or A2 precedes
A1.

So Unordered would be the subset of Split+Join in which the parallel
processes are non-concurrent.

                                             -- Drew


-- 
                                             -- Drew McDermott
                                                Yale University CS Dept.

Received on Wednesday, 22 September 2004 15:03:45 UTC