0

Threads and parallel programming is really confusing the heck outta me. In this book, at page 9, the problem stated is that though a thread might be scheduled and put in the ready state, it does not necessarily mean that it has acquird a lock.

Briefly put, a thread (say t1) waiting on a lock is notified via a condition_variable and the thread is put in the ready state, but not executed. But just before it can run anything, another thread is scheduled (say t2) and executed. This means that the condition under which t1 assumes it is woken up no longer holds.

Does this imply that merely scheduling a thread or putting it the ready state does not mean that it acquired a lock? If this is the case, must I always put the precondition in a while loop? Is this another possible meaning of a spurious wakeup? Also, what other cases like this must I be aware of?

I was always under the assumption that if a thread is woken up from a wait (which is not a spurious wakeup), it immediately acquires the lock (wakeup = lock acquired, under this circumstance), as the kernel keeps track of this.

This question is in close relation to my other question posted here.

Thanks.

Where can I ask these noob questions, in sort of an interactive format with follow-up questions? These seem too dumb for stackoverflow.

B_Dex_Float
  • 142
  • 2
  • 11
  • Please feel free to drop some links to books and resources where parallel programming, C++ threading are dealt with _in detail_. I'm having trouble finding resources. Books would be the _ideal_ resource. Thank you. – B_Dex_Float Feb 09 '20 at 19:29

1 Answers1

0

must I always put the condition in a while loop?

It's good practice to do so. Even if you know that on some particular hardware platform and OS, it's impossible for the wait() to return unless the condition is true; it could behave differently after the OS has been updated, or it could behave differently if your code gets moved to a different platform, or it could behave differently after some change is made to your code.

If you ever work developing "enterprise" software, then changes like that can and will happen. Might as well start learning good habits that can help to avert future disasters.

I was always under the assumption that if a thread is woken up from a wait (which is not a spurious wakeup), it immediately acquires the lock

You can safely assume that wait() will not, under any circumstances, ever return until the mutex has been re-locked. The whole wait()/notify() paradigm depends on it behaving in that way.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57
  • Yes, I do understand that `wait` only returns when the lock is held. My question is more specific. If it's the kernel tracking locks/mutexes, does it mean even before the execution of first instruction in `wait`, the lock is 'held'? Or is there some code in the internal implementation of `wait` that returns only if was able to acquire the lock? If it's the latter, then I can understand that `wait` can be interrupted before lock acquisition, potentially rendering precondition false. Knowing what of the above 2 is true will help me reason with 'supurious wakeups'. – B_Dex_Float Feb 09 '20 at 19:23
  • Also, could you kindly guide me to some books and resources where I can read these concepts _in real depth?_ My OS books aren't clarifying all my doubts. This, and a book covering C++ multithreading in depth. Reading these would help me understand both the underlying concepts and their implementation, helping me reason with these. Basically, after reading them, I should be able to answer questions like the one I posted. I would really appreciate resources where these are dealt _in detail_. Thank you for your time. – B_Dex_Float Feb 09 '20 at 19:26
  • @B_Dex_Float, Sorry. I am not a committer for any operating system or language support library. I don't think I'm qualified to talk about the details of any particular implementation of wait() and notify() or, why the implementors chose to do it in a particular way. As for books,... Those will only take you part of the way. Some questions can only be answered by reading the actual source code, or by conversing with the people who wrote it. Linux and GNU source code are freely available on-line. – Solomon Slow Feb 09 '20 at 19:33
  • Thank you for the input! But if you do have any books in mind, even if they take only so far, please feel free to drop some links as I sure as heck could use them at my current level of understanding (I'm kinda a beginner at this, so all help helps!). Thank you! – B_Dex_Float Feb 09 '20 at 19:47