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

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.
  • Comment on Re^13: Threads sharing global variable (disingenous)

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

    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]
      So in a nutshell you are claiming that: two threads can, in fact, both acquire and simultaneously hold a lock on a shared variable?

      NO! How on earth can you misread what I wrote so grossly?

      I wrote: "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."

      Sorry if English is not your first language, but those two statements are completely (and unmistakably) different; unrelated; Almost, but not quite polar opposites.

      Do you agree, that two threads, that have no need for access to a shared resource, can both run concurrently. (I'm gonna assume that you do, because anything else would be ridiculous.)

      Therefore, it is a simple step to envisage two threads that each have lots of stuff to do; that each occasionally need to access the same resource -- say a shared variable -- running concurrently without any locks in place.

      Now most of the time neither of them hold any locks. They just go about their business, each essentially completely ignorant of the other threads existence.

      And then, when either one of them needs access to the shared variable, it acquires the lock, makes its change and releases it again. And most of the time, the other thread will still be totally unaware of the first threads existence.

      And when the second thread needs to access the shared variable, it does exactly the same thing: acquires the lock; makes its change; and releases the lock. And the first thread need never be aware of any of it.

      Occasionally, they will both attempt to acquire the lock at (roughly) the same time. One will succeed, and the other will block -- at the lock() -- when the one that succeeded finishes, it simply releases the lock. It doesn't even need to signal or broadcast.

      When the winner releases the lock, the other thread's lock() succeeds and returns, it makes its change, and releases. All done.

      No possibility for deadlocks; no possibility for missed signals; no unnecessary contention; and no lock-stepping of threads.

      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]

        I am so sorry! In a previous node, when I asserted

        The threads cannot both hold the lock. One must sit in cond_wait() while the other is working.
        ... I assumed that a native speaker would be able to correctly read this in context of the discussion thread. My message was not that a program may not have concurrently executing threads. Goodness gracious, no. The implication was that the sample code, as presented by ikegami, cannot have two of its lock-protected sections executing in parallel. Both while loops are protected (with the sole exclusion of an internal region inside the cond_wait() routine).

        In retrospect, I may have made a misjudgment, especially in light of the misspelled /disingenous/ in the title.

[reply]
[d/l]

In Section Seekers of Perl Wisdom