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
In reply to Re^8: Threads sharing global variable
by beech
in thread Threads sharing global variable
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |