in reply to Re^16: Why is the execution order of subexpressions undefined?
in thread Why is the execution order of subexpressions undefined?

You've just rediscovered the fact that shared-state concurrency is a nasty mess. Humans aren't smart enough to use it correctly in anything but the most controlled conditions. Declarative concurrency, on the other hand, is possible to understand. Check into Concepts, Techniques, and Models of Computer Programming. They've also got a wiki

Replies are listed 'Best First'.
Re: Shared state concurrency is a no, no
by BrowserUk (Patriarch) on Apr 14, 2005 at 22:40 UTC
    Humans aren't smart enough to use it correctly in anything but the most controlled conditions.

    And that is why I am asking for "controlled conditions".

    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]
[d/l]
      No, controlled conditions in this case means one or two shared state variables wrapped in a mutex and explicit concurrency. None of this willy-nilly everthing-shared-state-plus-autothreading monkey business. And even then you'll probably still have deadlock problems.
[reply]
        Bug-free concurrency certainly is possible, it just requires more brain power than the average programmer possesses. Some people can do it with a handful of shared state variables wrapped in seperate mutexes and still prevent deadlocks just by thinking through their code very carefully.
[reply]

In Section Seekers of Perl Wisdom