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

This is your most disingenuous post to date. (The latest in a very long line.)

Below is a simple experiment using your exact posted code from Re^2: Threads sharing global variable; that anyone running windows and a few versions of perl installed, can conduct for themselves in around five minutes, and see your dishonesty for themselves.

This is your code running under This is perl, v5.10.1 built for MSWin32-x64-multi-thread:

<Reveal this spoiler or all spoilers in this node or all in this thread>

Summary: It produces 287(*) lines of output before hanging. (Varies from run to run; but that's typical.)

This is your code running under This is perl 5, version 18, subversion 4 (v5.18.4) built for MSWin32-x64-multi-thread:

<Reveal this spoiler>

Summary: It produces 817* lines of output. (Usually runs a little longer than under 5.10, but of 20 runs this was the most output before hanging.)

This is your code running under This is perl 5, version 22, subversion 0 (v5.22.0) built for MSWin32-x64-multi-thread:

<Reveal this spoiler>

Summary: It produces 479* lines of output before hanging! (After 10 runs the average was around 700 lines, but that included one run that gave nearly 2000 lines and another that produced 17.)

Your code hangs under Windows, regardless of the version. That it produces any output at all is pure chance.

I'm also now firmly convinced that it will hang everywhere -- even under Linux -- if left running long enough, because a signal will eventually be missed and it will deadlock. This is inevitable; but is an exercise for someone else to (dis)prove.

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.

Replies are listed 'Best First'.
Re^8: Threads sharing global variable (disingenous)
by ikegami (Patriarch) on Mar 09, 2016 at 17:36 UTC

    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)

[reply]
[d/l]
[select]
      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]

        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]

In Section Seekers of Perl Wisdom