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.

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

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.

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.

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.

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.