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

The signaling code is pretty awful. Lots of unnecessary locking and unlocking, and it's far more complicated than it needs to be. Here it is improved: 

use threads;
use threads::shared;
use Thread::Queue;

my $a :shared = 0;
my $q = Thread::Queue->new();

sub set_positive {
    lock $a;
    while (1) {
        cond_wait($a) while $a > 0;

        $a = int(rand() * 100) + 1;
        cond_signal($a);

        $q->enqueue($a);
    }
}

sub set_zero {
    lock $a;
    while (1) {
        cond_wait($a) while $a == 0;

        $a = 0;
        cond_signal($a);

        $q->enqueue($a);
    }
}

sub printer {
    while (1) {
        my ($v_a, $v_b) = $q->dequeue(2);
        print "At printer $v_a $v_b\n";
    }
}

threads->create($_) for qw( set_positive set_zero printer);
$_->join for threads->list;

[download]

cond_wait should always be used as cond_wait($lock) while !desired_condition();.

cond_signal (or cond_broadcast) is used when you change something checked by a thread's desired_condition().

Remember, your lock is released when you call cond_wait, and re-obtained before cond_wait returns.

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

    What do you get when you run this program ikegami?

    I get one single line of output, i other words, it doesn't work

    Like BrowserUk says, you lock the variable in the outer scope, and that lock is never released -- not an improvement

[reply]

      I grabbed ikegami's code and ran it against perls 5.8.8, 5.10.1, 5.16.1, 5.18.1, and 5.22.1 on Linux/amd64, and it spat out huge amounts of data for each one. So, if you're only getting a single line of output, I have to wonder what's so different in your environment as to break this. However, that it works here indicates that the locking isn't a problem by itself.

[reply]
        I have to wonder what's so different in your environment as to break this

        Simple.

        threads::shared cond_* variables and associated APIs, map directly to Pthreads condition variables; thus, they have a fair chance of working on platforms that have native pthreads.

        Conversely, Windows has no direct analogy to pthreads condition variables, hence they have to be emulated using those synchronisation primitives that Windows does provide. That emulation is done crudely, and badly and has to my knowledge never worked correctly. Hence why I have avoided them like the plague.

        For the most part, if used sensibly -- which means not relying on the (long identified as broken) edge-trigger semantics that underly cond_wait() -- threads::shared's emulated cond_vars can be used on Windows; but doing so successfully requires an understanding of their inherent limitations (which exist everywhere, but are exacerbated by the crude emulation on Windows), and that requires that the designer has actually written and debugged real-life code doing real work; not just thrown together a few do-nothing, trivial examples for the purposes of establishing cred.

        The sad part is, Window's native synchronisation primatives are extremely rich and powerful; and do not suffer the Achilles heel of Pthread's one and only synchronisation mechanism -- namely, spurious triggers.

        For Far more than You Ever Want To Know about the problems of trying to accurately emulate Pthreads cond_vars (broken) semantics on windows see: 3. Implementing Condition Variables on Win32.

        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]
        Hi Tanktalus, I'm running on windows

        update:

        FWIW, if I only move the lock in set_positive inside the while loop, still just one line of output.

        If I only move the lock in set_zero inside the while loop, a couple thousand lines of output, and then it locks hangs

        If I move both the lock statements inside the while loop, like BrowserUk wrote, it just keeps running and doesn't hang

[reply]
      you lock the variable in the outer scope, and that lock is never released -- not an improvement

      Provided that the OP only ever wants to do exactly what his OP code attempts to do -- which is nothing useful -- then ikegami's code has a fair chance of running on platforms that support condition variables natively.

      But, even on those platforms, if, as seems almost certain, the OPs code is just a cut-down placeholder for his real application, and there is more (almost anything more) going on inside those while loops (and there has to be, because in their current form they do nothing useful), then every single extra clock-cycle spent doing that 'more' before looping back to the cond_wait() call, is time that other threads ought to be able to make forward progress, but can't because ikegami's code doesn't release the cond-var; except for the briefest of windows when it calls cond_wait().

      So, for instance if the user adds a simple call to the regex engine that runs for (say) 0.1 seconds; then the ratio of the cond_wait() release (say) 0.0001 seconds to that trivial amount of useful processing is 1000:1. And that means that all the other threads that are blocking and syncing on that cond_var can AT MOST expect to make forward progress for no more than 1/1000 of a second in every second. And if there are two other threads, then they can AT MOST make progress for on 1/1000 of a second in every two seconds, and so on. (And if they themselves are also doing other stuff in their while loops, then the odds that one thread will actually be waiting, ready to run, in the minusculey brief period when another thread releases the cond_var; becomes vanishingly small.

      The upshot is, that in addition to not working on windows, his code provides a disastrous example of using cond_vars, because it will only ever work (on some platforms) for entirely trivial, do nothing examples; and will break every time, (everywhere), for any program that does real work, and attempts to use the pattern of usage he demonstrates.

      The difference between playing and knowing. Not that it will undo the entirely wrong upvotes by those who vote based upon hero worship rather than content.

      Not that the votes mean anything; except that when people coming looking for solutions, the "highest first" sorting of nodes will likely push his node up, and so seekers will get lumped with his example, and when it breaks for their real world usage, they'll be left floundering trying fix what they will perceive as bugs they introduced; when in fact those bugs are inherent in the example code they downloaded.

      His code is like a latent virus, biding its time before causing the epidemic. (But what does he care; he's got his up-votes and bolstered his rep., which is all he cares about.)

      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]

        Completely bogus analysis.

        The cond_wait() mechanism is useful for synchronisation ie cooperative threading. Here it does exactly what it intends to do — which is to make sure only one thread (or code section) is running at any given time. If the forward progress blocks in some thread, it is by design; the thread waits until some goalpost is reached elsewhere.

[reply]
[d/l]
Re^3: Threads sharing global variable
by BrowserUk (Patriarch) on Mar 02, 2016 at 22:29 UTC
    Lots of unnecessary locking and unlocking,

    And your version is sh*te! (Hint:locks should be held for as small a scope and for as little time as possible!). It may work for this specific do nothing, trivial example, but is entirely useless as a generic model of usage

    Threads that lock all their shared variables when they start and never release them. What a great idea. I wonder why nobody's thought of doing that before(*).

    And, as you you know, I'm not interested in your opinion (on anything), so feel free to feed your BS to the OP if you must, but stop polluting my day.

    *Oh right. Because it only makes sense in a lock-stepped latching scenario, and besides that real examples of the need for that are as rare a rocking horse droppings; it is a completely stupid way to use threads.

    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]

      Threads that lock all their shared variables when they start and never release them.

      Are you an idiot or a troll? I'm tired of your endless, rude and completely wrong "corrections". Learn to read.

      And your version is sh*te! (Hint:locks should be held for as small a scope and for as little time as possible!)

      The lock is held no longer in my version than it is in your version[1]. Go read the post again. Specifically, the notes at the bottom. They specifically address your misconceptions.

      1. In fact, mine holds it for a shorter period, but only by milli- or nano-seconds.
[reply]
        I'm tired of your endless, rude ...

        I'm easily avoided.

        For the rest; you know better, but typically of you, you'll prevaricate and obfuscate until the bitter end.

        Which is why I'd be only too happy if you never felt the need to direct your BS at me ever again.

        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