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

The signal can't be missed as long as cond_signal($c) and the cond_wait($c) while !desired_condition(); are only called when you have the lock. That's why it works for your code. That's why it works for my code. There's a bug in your OS (or emulation) otherwise.

(Stopped test after it produced 6,951,816 lines and 110,673,920 bytes of output)

Replies are listed 'Best First'.
Re^9: Threads sharing global variable (disingenous)
by BrowserUk (Patriarch) on Mar 09, 2016 at 17:49 UTC
    The signal can't be missed

    Of course. Ikegami knows better than the rest of the entire world. (At least, he thinks he does!)

    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]

      But if the signalling thread signals before the other thread(s) reach the wait(); that signal can be lost.

      What they mean by "lost" is that it doesn't do anything if there's noone currently in a cond_wait. By that definition, I agree the signal can be "lost".

      But that's not a problem. That's why you have to get the lock and check the condition before cond_wait. If you do that, you're good. It doesn't matter that the signal is "lost" because you don't even try to wait for it.

      Seems that something that should be atomic isn't on Windows. I would stay far away from cond_* there!

[reply]
[d/l]
[select]
        What they mean by "lost" is that it doesn't do anything if there's noone currently in a cond_wait. By that definition, I agree the signal can be "lost".

        Okay. Now we're getting somewhere.

        So, if the other thread is still busy, and hasn't looped back to its cond_wait(), by the time 'this' thread calls cond_signal(), then when that other thread DOES reach its cond_wait() it'll block.

        Meanwhile, 'this' thread will never signal again, until it has seen a signal from that other thread; which it never will because it'll never come out of its cond_wait() because it missed the signal that would have released it.

        The very definition of deadlock.

        But that's not a problem.

        Hopefully, you now see, it is a problem.

        And that is an admission of your 'broken' code; though I'm sure you'll continue to argue.

        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]

      I once enjoyed browsing through the articles on PerlMonks. What isn't fun is the rudeness towards other monks. Why the rudeness? But maybe, ikegami was rude in his response to your demonstration.

      The interesting thing is that BrowserUk's demonstration runs with the lock obtained outside the while loop. This is also true on the Windows platform.

      sub set_positive {
   lock $a;
   while (1) {
      ...
   }
}

sub set_zero {
   lock $a;
   while (1) {
      ...
   }
}

      [download]

      A long time monk ikegami made a correct statement when stating the lock is re-obtained before cond_wait returns. In fact, that is mentioned in the threads::shared documentation.

      Another finding is the printer output containing "0 0" indicating set_zero enqueued twice in a row. Also, the output contains two positives indicating set_positive enqueued twice in a row. These occur often in the output. The OP does not mention if such occurrence is valid, so am not sure.

      Is there a code of conduct for PerlMonks? The reason is that there is no joy in seeing monks attacking one another. Recently, the Mojolicious team added a section titled Code Of Conduct to a guide. Is there anything like that for PerlMonks?

[reply]
[d/l]

        he interesting thing is that BrowserUk's demonstration runs with the lock obtained outside the while loop.

        Except that it doesn't, thats ikegamis code -- get some sleep or something

[reply]
        Why the rudeness?

        History, correctness, and bare-faced lies.

        And because sometimes life is too short to be polite about crap code.

        And because you don't become an expert in anything by reading the manual, except for "expert at reading the manual".

        Real expertise requires you to have written real code, that's been run in real, live systems, and to have debugged it, and found the limitations of the manual's api descriptions.

        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]

        Today, am not getting 2 positives on the same line. But am still getting two zeros when running the solution posted by BrowserUk.

        ...
At printer 0 0
...
At printer 0 0
...
At printer 0 0
...
At printer 0 0
...

        [download]

        The OP does not mention if this is valid. Therefore, maybe okay.

[reply]
[d/l]

In Section Seekers of Perl Wisdom