he must have known, ... that his code hangs on windows
But, you have said it yourself, in here,
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 here,
The best I've been able to conclude is that the signal is simply not seen by the waiters; because of the crude and sloppy emulation.
... and yet you chose to make use of said emulation, with due care and diligence as it would seem.
Lesser men tend to be lacking in such deep insight, that apparent requirement in writing exemplary threaded code. Please be understanding with us!
Would it be possible to share this knowledge, to outline the guiding principles and design considerations, so as to allow us to build robust, working solutions ourselves, all the while avoiding the dangerous pitfalls, taboos and uncertainties? Much obliged!
| [reply] |
But, you have said it yourself, in here
That's not the point. The points are:
- He posted his code as a "correction" to mine; which by the logic and practice of basic Locking & Syncing; his code is broken, by design, everywhere.
Even if it never hangs on Linux -- and no one has convinced me that it won't eventually -- it is still broken on Linux, be it is a logical nonsense.
It makes no sense to run two threads; and then constrain them to only ever allowing one of them to do anything at a time. None whatsoever.
That it demonstrates its brokenness so quickly and obviously on Windows is just a side issue.
- He posted: "For me, it works fine in Windows too."; when he knew better.
...
Would it be possible to share this knowledge, to outline the guiding principles and design considerations, so as to allow us to build robust, working solutions ourselves, all the while avoiding the dangerous pitfalls, taboos and uncertainties? Much obliged!
I assume that is sarcasm. But, the answer is no. I have no idea how to condense and neatly parcel up 13 years of Perl threading experience; let alone the accumulated knowledge, feel and intuition from writing literally hundreds of threaded programs, big & small, in C, C++, Java, and half a dozen or more other languages that I've done since I wrote my first threaded program under OS/2 in 1987.
Maybe in the future they'll be able to do brain dumps; till then, the only way I know of to learn stuff, is to use it. For real.
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] |
The following resolves the printer output having two zeros. That led to the confusion. It looks like somebody already mentioned it.
$a = int(rand() * 100) + 1;
The OP presented an interesting problem. Seeing the double zeros led me on a wrong path. Please, for future monks testing your solution, can you kindly add + 1 inside set_positive.
sub set_positive {
lock $a;
while (1) {
if ($a == 0) {
$a = int(rand() * 100) + 1;
$q->enqueue($a);
print "At set_positive: $a\n";
} else {
cond_wait($a)
}
cond_broadcast($a);
}
}
Thank you.
| [reply]
[d/l]
[select] |
sub set_positive {
while (1) {
lock $a;
if ($a == 0) {
$a = int(rand() * 100) + 1;
$q->enqueue($a);
print "At set_positive: $a\n";
} else {
cond_wait($a)
}
cond_broadcast($a);
}
}
| [reply]
[d/l] |
can you kindly add + 1 inside set_positive.
I've been reluctant to make *any* modifications to my posted code lest it become a source of "you changed your code" contention, and a rod for my back.
Hopefully, that possibility has now past and the change is made.
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] |