in reply to Re^35: Why is EO undefined? (More details!)
in thread Why is the execution order of subexpressions undefined?

Either both functions get the same semaphore, and in effect, they run in serial. Or they don't, and the semaphore is in principle bogus.

Wrong. See WaitForMultipleObjects--but in case the source of the reference scares you, here is the salient point:

The WaitForMultipleObjects function returns when any one or all of the specified objects are in the signaled state.

Emphasis added

And there's no order of execution here, since you don't know in which order the functions are going to be performed.

Only by your definition, not mine. My definition explicitly allows concurrent derivation of the operands to any non-serialising, binary operator.

And the principle is well known. It is termed "dataflow threading" or Sheduled Dataflow Architecture.

But we've said this dozens of times already.

Wrongly each time.

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?

Replies are listed 'Best First'.
Re^37: Why is EO undefined? (More details!)
by Anonymous Monk on Apr 18, 2005 at 13:02 UTC
    My definition explicitly allows concurrent derivation of the operands to any non-serialising, binary operator.
    Oh, sure, your definition allows it. Noone is questioning that. Your definition isn't the point.

    The point being made is that in general, any implementation will effectively be serialized.

    You haven't made a convincing argument that the run-time can figure out which parts can be run in parallel, without violating a defined order of execution.

[reply]

      The runtime doesn't need to figure anything out.

      If both operands to any, non-serialising, binary operator are non-simple variables (there'd be no chance for concurrency if either is), and the methods which produce those operands are marked (by their authors) as being parallelisable, then the runtime can parallelise them.

      The very fact that they are parallelisable and the programmer has placed them within the same (simple)expression, either side of a non-serialising operator, means that the runtime can call the threaded versions of both methods and wait for them both to complete before continuing.

      But, for that to be workable, the programmer must be able to guarentee the execution order of the derivation of any parameters that will be passed to those two methods.

      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?
[reply]
        I think we are in violent agreement. Except where the entire universe calls this undefined order of execution, you call it defined order.

        That doesn't matter.

        Since both you, and the rest of the world are saying that you may only write: 

            EXPR1 OP EXPR2

        [download]
        if it doesn't matter whether EXPR1 or EXPR2 gets evaluated first.
[reply]
[d/l]

In Section Seekers of Perl Wisdom