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

So by design, it doesn't get past one line of output? except by accident on linux?
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?

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()?

Replies are listed 'Best First'.
Re^8: Threads sharing global variable
by beech (Parson) on Mar 06, 2016 at 06:56 UTC

    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

[reply]
[d/l]
[select]

      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]

In Section Seekers of Perl Wisdom