in reply to Re^10: Threads sharing global variable (disingenous)
in thread Threads sharing global variable

What they mean by "lost" is that it doesn't do anything if there's noone currently in a cond_wait. By that definition, I agree the signal can be "lost".

Okay. Now we're getting somewhere.

So, if the other thread is still busy, and hasn't looped back to its cond_wait(), by the time 'this' thread calls cond_signal(), then when that other thread DOES reach its cond_wait() it'll block.

Meanwhile, 'this' thread will never signal again, until it has seen a signal from that other thread; which it never will because it'll never come out of its cond_wait() because it missed the signal that would have released it.

The very definition of deadlock.

But that's not a problem.

Hopefully, you now see, it is a problem.

And that is an admission of your 'broken' code; though I'm sure you'll continue to argue.

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^11: Threads sharing global variable (disingenous)

Replies are listed 'Best First'.
Re^12: Threads sharing global variable (disingenous)
by Anonymous Monk on Mar 09, 2016 at 19:59 UTC

    So, if the other thread is still busy, and hasn't looped back to its cond_wait(), by the time 'this' thread calls cond_signal(), then when that other thread DOES reach its cond_wait() it'll block.
    The threads cannot both hold the lock. One must sit in cond_wait() while the other is working.

[reply]
[d/l]
      One must sit in cond_wait() while the other is working.

      Why? That's complete nonsense.

      Both threads can be neither holding the lock, nor waiting for a lock; they can just be doing stuff that doesn't involve using the shared resource.

      The most basic principle of locking is that you hold lock for a short a period as possible. Ie. They should only attempt to acquire the lock immediately before they are ready to modify the shared resource.

      That's Locking & Syncing 101. That way, if the other thread isn't holding the lock, the attempt to acquire it succeeds immediately, and they can get straight on to making the modification and releasing the lock.

      With luck, the other thread was busy with its other stuff for the entire time and was neither affected (slowed down) by the action of the first thread, nor imposed any delay upon the first thread.

      Ditto vice versa. When the second thread wants to make its change, if the first thread isn't holding the lock, then it can get straight on with its change, without ever affecting or being affected by the other thread.

      And that's the Holy Grail of resource sharing; free running (non-blocking) shared resource access for both (all) threads most if the time, with blocking only occurring: a) occasionally; b) for very short periods; when the dynamic periodicities of the threads happen to coincide.

      What you are suggesting -- is what Ikegami's code does -- is to make it so that only one thread can ever be doing *anything* at any given time. And that stupid. You -- quite literally -- would be better off using a single thread and just interleaving the code from the two threads.

      It would achieve the same processing, with better performance; and the added bonus that you'd be guaranteed not to create deadlocks.

      The purpose of locking is not to ensure that only one thread can run at a time; it is to ensure that only one thread can access the shared resource at any given time.

      Which makes what you are suggesting -- and what Ikegami implemented -- broken. By design!

      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]

        So in a nutshell you are claiming that: two threads can, in fact, both acquire and simultaneously hold a lock on a shared variable?

[reply]

In Section Seekers of Perl Wisdom