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

But if the signalling thread signals before the other thread(s) reach the wait(); that signal can be lost.

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

But that's not a problem. That's why you have to get the lock and check the condition before cond_wait. If you do that, you're good. It doesn't matter that the signal is "lost" because you don't even try to wait for it.

Seems that something that should be atomic isn't on Windows. I would stay far away from cond_* there!

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

      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]

In Section Seekers of Perl Wisdom