in reply to Re^7: baton passing threads and cond_signal
in thread baton passing threads and cond_signal

If one thread maintains a persistant lock on the variable, how would the other thread ever obtain a lock? Without obtaining a lock, cond_wait doesn't work.

  • Comment on Re^8: baton passing threads and cond_signal

Replies are listed 'Best First'.
Re^9: baton passing threads and cond_signal
by ikegami (Patriarch) on Aug 22, 2007 at 16:34 UTC

    There's no persistant lock. cond_wait releases the lock, allowing other threads to cond_broadcast. cond_wait re-obtains the lock on awakening.

    You should reread my node. I added this critical paragraph:

    The problem might be that your system's implementation of cond_wait isn't atomic (while it should be), allowing a signal to come in after cond_wait unlocks $baton, but before cond_wait starts waiting.

[reply]
[d/l]
[select]
      The problem might be that your system's implementation of cond_wait isn't atomic

      Which would be a bug worth reporting. An easy way to verify this would be to run the code above without the yields on single cpu Linux system and see if the problem occurs there?

[reply]

        Can we take that the lack of a refutation that this problem also occurs on a single cpu Linux system to mean that the problem lies in the semantics of the whole cond_* mechanism and not just in the Win32 emulation of it?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom