Is often convenient associating only one condition

Info icon This preview shows pages 6–8. Sign up to view the full content.

is often convenient, associating (only) one condition variable with each lock (the same object) is not always what you want. There are three methods: wait should be called only while holding the lock for the object. (Typically, the call is to this.wait so the lock this should be held.) The call will atomically (a) block the thread, (b) release the lock, and (c) register the thread as “waiting” to be notified. (This is the step you cannot reasonably implement on your own; there has to be no “gap” between the lock-release and registering for notifica- tion else the thread might “miss” being notified and never wake up.) When the thread is later woken up it will re-acquire the same lock before wait returns. (If other threads also seek the lock, then this may lead to more blocking. There is no guarantee that a notified thread gets the lock next.) Notice the thread then con- tinues as part of a new critical section ; the entire point is that the state of shared memory has changed in the meantime while it did not hold the lock. notify wakes up one thread that is blocked on this condition variable (i.e., has called wait on the same object). If there are no such threads, then notify has no effect, but this is fine. (And this is why there has to be no “gap” in the imple- mentation of wait .) If there are multiple threads blocked, there is no guarantee which one is notified. notifyAll is like notify except it wakes up all the threads blocked on this con- dition variable. The term wait is standard, but the others vary in different languages. Sometimes notify is called signal or pulse . Sometimes notifyAll is called broadcast or pulseAll . Here is a wrong use of these primitives for our bounded buffer. It is close enough to get the basic idea. Identifying the bugs is essential for understanding how to use condition variables correctly. class Buffer<E> { // not shown: an array of fixed size for the queue with two indices // for the front and back, along with methods isEmpty() and isFull() void enqueue (E elt) { synchronized ( this ) { if ( isFull ()) this . wait (); CPEN 221 – Fall 2016
Image of page 6

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

Reader/Writer Locks, Condition Variables and Other Synchronization Primitives 7 ... do enqueue as normal ... if ( ... buffer was empty (i. e ., now has 1 element) ...) this . notify (); } } E dequeue () { synchronized ( this ) { if ( isEmpty ()) this . wait (); E ans = ... do dequeue as normal ... if ( ... buffer was full (i. e ., now has room for 1 element) ...) this . notify (); return ans; } } } Enqueue waits if the buffer is full. Rather than spinning, the thread will consume no resources until awakened. While waiting, it does not hold the lock (per the definition of wait ), which is crucial so other operations can complete. On the other hand, if the enqueue puts one item into an empty queue, it needs to call notify in case there are dequeuers waiting for data. Dequeue is symmetric. Again, this is the idea — wait if the buffer cannot handle what you need to do and notify others who might be blocked after you change the state of the buffer — but this code has two serious bugs. It may not be easy to see them because thinking about condition variables takes some getting used to.
Image of page 7
Image of page 8
This is the end of the preview. Sign up to access the rest of the document.
  • Fall '17
  • satish
  • producer, condition variables, reader/writer locks

{[ snackBarMessage ]}

What students are saying

  • Left Quote Icon

    As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.

    Student Picture

    Kiran Temple University Fox School of Business ‘17, Course Hero Intern

  • Left Quote Icon

    I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.

    Student Picture

    Dana University of Pennsylvania ‘17, Course Hero Intern

  • Left Quote Icon

    The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.

    Student Picture

    Jill Tulane University ‘16, Course Hero Intern