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

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.

Replies are listed 'Best First'.
Re^10: baton passing threads and cond_signal
by Anonymous Monk on Aug 22, 2007 at 16:47 UTC
    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]

        The people discussing perlbug 41574 think it's specific to (some versions of) Windows.
        The only person in this thread reporting the problem uses WinXP.
        I only have access to Windows machines.

        I'd take the lack of refutation as nothing more than people not reading the thread this deep.

[reply]

In Section Seekers of Perl Wisdom