in reply to Re^45: Concurrency in Oz [Was: Why is EO undefined?]
in thread Why is the execution order of subexpressions undefined?

Counter-example: (from: http://suif.stanford.edu/papers/ppopp01.pdf)

When executing a program in parallel, the Jade implementation preserves the program’s semantics by maintaining the serial execution order for tasks with conflicting side effect specifications. For example, two tasks that write the same shared data object have conflicting side effects, and must execute sequentially in the program’s serial execution order. The Jade implementation must also preserve the serial execution order between a task that writes a shared data object and another task that reads the same object. Of course, tasks accessing disjoint sets of objects or reading the same object can execute concurrently.

Emphasis added.

Wiki entry or a paper from Stanford?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
Rule 1 has a caveat! -- Who broke the cabal?
  • Comment on Re^46: Concurrency in Oz [Was: Why is EO undefined?]

Replies are listed 'Best First'.
Re^47: Concurrency in Oz [Was: Why is EO undefined?]
by Anonymous Monk on Apr 18, 2005 at 21:56 UTC
    • Of course, tasks accessing disjoint sets of objects or reading the same object can execute concurrently.
    • Concurrency is what happens when the order of evaluation of expressions is unspecified
    What kind of thought process sees a conflict between those two statements? After all "accessing disjoint sets of objects...can execute concurrently" means "it doesn't matter which order the reads occur". Which translates to "you don't have to specify which order the reads occur in". And finally you reach the same conclusion: "unspecified order of reading means you can do it concurrently"
[reply]

In Section Seekers of Perl Wisdom