in reply to Shared state concurrency is a no, no
in thread Why is the execution order of subexpressions undefined?

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?

Replies are listed 'Best First'.
Re^2: Shared state concurrency is a no, no
by Anonymous Monk on Apr 14, 2005 at 22:53 UTC
    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]
        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.

        Show me please.

        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]

In Section Seekers of Perl Wisdom