Re^4: Threads sharing global variable

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.

Comment on Re^4: Threads sharing global variable

Replies are listed 'Best First'.
Re^5: Threads sharing global variable by Anonymous Monk on Mar 05, 2016 at 09:45 UTC
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^6: Threads sharing global variable by BrowserUk (Patriarch) on Mar 05, 2016 at 13:47 UTC
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.	[reply]
Re^7: Threads sharing global variable by ikegami (Patriarch) on Mar 09, 2016 at 13:44 UTC
But with ikegami's cockeyed design, that simply isn't possible. Please disregard this misinformation. His solution blocks just as much as mine does.	[reply]
Re^6: Threads sharing global variable by beech (Parson) on Mar 05, 2016 at 10:04 UTC
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	[reply] [d/l]
Re^7: Threads sharing global variable by Anonymous Monk on Mar 05, 2016 at 11:16 UTC
So by design, it doesn't get past one line of output? except by accident on linux? No, it is not an accident that it works on linux as it is supposed to. I'd wait for someone who could replicate your problem (on windows machines). Can't see any ticket on rt; maybe you should report this? In any case, I suspect the misunderstanding here is about the way locking happens. In ikegami's code, the variable `$a` is unlocked the whole time that the threads spin in cond_wait. Only after the cond_signal does one thread lock, run the loop, and then block again. (But then, cond is always resignaled, so one thread is always working.) Could it be a signal is lost somehow? What do you get when you replace `cond_signal()` by `cond_broadcast()`?	[reply] [d/l] [select]
Re^8: Threads sharing global variable by beech (Parson) on Mar 06, 2016 at 06:56 UTC
Re^9: Threads sharing global variable by Anonymous Monk on Mar 06, 2016 at 14:16 UTC
Some notes below your chosen depth have not been shown here

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

It's by design alright. Broken by design!