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] |
BrowserUk runs windows
Did he run ikegami's code?
Changing cond_signal to cond_broadcast changes nothing
Yeah, I didn't expect it would. The point is, as far as I can see, the code is race-free and it can not deadlock. Can you please explain, how exactly does it hang? Can you debug it? Can you detail the scenario that leads to deadlock? Describe the state of the program where and as it hangs?
Another thought: maybe try eliminate the use of Thread::Queue. Just keep $prev in printer, count number of $changes and if ($changes >= 100) terminate "with Success".
| [reply] |