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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
| [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.
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] |
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] |
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?
BrowserUk runs windows
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()?
Changing cond_signal to cond_broadcast changes nothing
If you add some print statements inside both subs, and then move lock statement inside set_zero, instead of getting a couple of thousand outputs from printer like you would without the extra print statement, you only get three lines from printer, whereas ikegamis original only produces one
So no, I don't believe the signals get lost, its just a race condition as BrowserUk explains , if you expect to do any real work you can't use ikegamis pattern as it only works by accident
| [reply]
[d/l]
[select] |