Re^17: Threads sharing global variable (disingenous)

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!

Comment on Re^17: Threads sharing global variable (disingenous)

Replies are listed 'Best First'.
Re^18: Threads sharing global variable (disingenous) by BrowserUk (Patriarch) on Mar 10, 2016 at 19:58 UTC
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. "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]

Replies are listed 'Best First'.

Re^18: Threads sharing global variable (disingenous)
by BrowserUk (Patriarch) on Mar 10, 2016 at 19:58 UTC

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.

"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]

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.