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.

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.

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

For me, it works fine in Windows too.

C:\Users\ikegami>perl a.pl
At printer 2 0
At printer 93 0
At printer 94 0
At printer 60 0
At printer 26 0
At printer 83 0
At printer 65 0
At printer 45 0
At printer 8 0
At printer 20 0
At printer 7 0
At printer 47 0
At printer 53 0
At printer 22 0
At printer 26 0
At printer 22 0
At printer 24 0
At printer 51 0
At printer 13 0
At printer 100 0
...
[download]

This is perl 5, version 16, subversion 3 (v5.16.3) built for MSWin32-x
+64-multi-thread
[download]

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.)

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.

Completely bogus analysis.

You called it. And you are right. Your analysis is completely bogus.

If your design is to lock-step all your threads so that only one thread can be doing *anything* at any given moment, then why are you using threads?

Better to simply call the appropriate functions serially in the correct order in a single thread; and avoid not just the overhead of threading & synching, but also the non-determanistic delays between those serial steps caused by requiring the scheduler to orchestrate the transfer of control between them; and also avoid competing with every other thread; not just those in your process, but in the entire system.

It simply makes no sense(*) to run serial pieces of processing in threads, and sequence them through the scheduler. None whatsoever.

The OPs example only makes sense if, between the synchronisation points, each thread has other work to be doing independently, and at different iteration rates. Ie. each synchronising thread also does other stuff in the loop between cond_waits(). But with ikegami's cockeyed design, that simply isn't possible.

It's by design alright. Broken by design!

* as in, it's nonsense!

---

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.

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.

So by design, it doesn't get past one line of output? except by accident on linux?

That doesn't make sense