Re^10: Threads sharing global variable

Did he run ikegami's code?

Of course I did. What else do you think triggered my reaction to it?

Can you please explain, how exactly does it hang?

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.

But even in *nix, cond_vars are known to be unreliable with waits spuriously returning even when no thread has signalled; and signals being missed if there are no waiters waiting at the exact moment of the signal. Edge-triggered semantics.

The best analogy I've seen for it is: playing phone tag in the days before voicemail and answering machines. Unless the recipient of the call is sat waiting by the phone when it rings; the call goes completely unnoticed.

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.

Comment on Re^10: Threads sharing global variable

Replies are listed 'Best First'.
Re^11: Threads sharing global variable by Anonymous Monk on Mar 06, 2016 at 15:00 UTC
The unlock-and-block part of `cond_wait()` is atomic; hence, by the time another thread acquires the lock, this first thread is guaranteed to be in a waiting state. Spurious signals cannot cause a deadlock either — the test condition is lock-protected and can only proceed when other thread has entered `cond_wait()` (with the cond variable set to the satisfaction of the first thread).	[reply] [d/l] [select]
Re^12: Threads sharing global variable by BrowserUk (Patriarch) on Mar 06, 2016 at 15:08 UTC
The unlock-and-block part of cond_wait() is atomic; hence, by the time another thread acquires the lock, this first thread is guaranteed to be in a waiting state. But if the signalling thread signals before the other thread(s) reach the wait(); that signal can be lost. lost signals. signals getting lost Lost wakeups in pthreads Lost signals - slow conditions a) spurious wakeups. b) lost signals; c) broadcast deadlock d) unfairness In our approach we use Petri nets to represent the key elements of interactions among threads to identify potential problems such as race conditions, lost signals, and deadlocks. A tool called C2Petri has been developed which converts C-Pthreads programs to the equivalent Petri net model. This tool helps verification of Pthread-based programs. Hundreds more... 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]
Re^13: Threads sharing global variable by Anonymous Monk on Mar 06, 2016 at 15:25 UTC
Depending on which thread wins the first lock, the first cond_signal() may be redundant. That is: If `set_positive()` won, it proceeds without waiting, and sends the unnecessary signal. This signal is dropped. But the `set_zero()` thread can then also proceed without `cond_wait()`, and subsequently sets the ping-pong going with its own `cond_signal()`.	[reply] [d/l] [select]
Re^14: Threads sharing global variable by BrowserUk (Patriarch) on Mar 06, 2016 at 15:34 UTC
Re^15: Threads sharing global variable by Anonymous Monk on Mar 06, 2016 at 15:45 UTC
Some notes below your chosen depth have not been shown here
Re^13: Threads sharing global variable by Anonymous Monk on Mar 06, 2016 at 15:31 UTC
Uh. Re: the links you have added. I'm not sure if I follow. The code you posted, is similarly at the mercy of the underlying signaling mechanism.	[reply]
Re^14: Threads sharing global variable by BrowserUk (Patriarch) on Mar 06, 2016 at 15:37 UTC