in reply to Re^7: Threads sharing global variable
in thread Threads sharing global variable

No, it is not an accident that it works on linux as it is supposed to. I'd wait for someone who could replicate your problem (on windows machines). Can't see any ticket on rt; maybe you should report this?

BrowserUk runs windows

In any case, I suspect the misunderstanding here is about the way locking happens. In ikegami's code, the variable $a is unlocked the whole time that the threads spin in cond_wait. Only after the cond_signal does one thread lock, run the loop, and then block again. (But then, cond is always resignaled, so one thread is always working.) Could it be a signal is lost somehow? What do you get when you replace cond_signal() by cond_broadcast()?

Changing cond_signal to cond_broadcast changes nothing

If you add some print statements inside both subs, and then move lock statement inside set_zero, instead of getting a couple of thousand outputs from printer like you would without the extra print statement, you only get three lines from printer, whereas ikegamis original only produces one

So no, I don't believe the signals get lost, its just a race condition as BrowserUk explains , if you expect to do any real work you can't use ikegamis pattern as it only works by accident

Replies are listed 'Best First'.
Re^9: Threads sharing global variable
by Anonymous Monk on Mar 06, 2016 at 14:16 UTC

    BrowserUk runs windows
    Did he run ikegami's code?

    Changing cond_signal to cond_broadcast changes nothing
    Yeah, I didn't expect it would. The point is, as far as I can see, the code is race-free and it can not deadlock. Can you please explain, how exactly does it hang? Can you debug it? Can you detail the scenario that leads to deadlock? Describe the state of the program where and as it hangs?

    Another thought: maybe try eliminate the use of Thread::Queue. Just keep $prev in printer, count number of $changes and if ($changes >= 100) terminate "with Success".

[reply]
      Did he run ikegami's code?

      Of course I did. What else do you think triggered my reaction to it?

      Can you please explain, how exactly does it hang?

      The best I've been able to conclude is that the signal is simply not seen by the waiters; because of the crude and sloppy emulation.

      But even in *nix, cond_vars are known to be unreliable with waits spuriously returning even when no thread has signalled; and signals being missed if there are no waiters waiting at the exact moment of the signal. Edge-triggered semantics.

      The best analogy I've seen for it is: playing phone tag in the days before voicemail and answering machines. Unless the recipient of the call is sat waiting by the phone when it rings; the call goes completely unnoticed.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        The unlock-and-block part of cond_wait() is atomic; hence, by the time another thread acquires the lock, this first thread is guaranteed to be in a waiting state.

        Spurious signals cannot cause a deadlock either — the test condition is lock-protected and can only proceed when other thread has entered cond_wait() (with the cond variable set to the satisfaction of the first thread).

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom