COMP 402: Production Programming ←  Concurrency Constructs  →

Today's Menu:

• Concurrency Constructs

Constructs for Concurrent Programming

• Volatile
  • Ensures visibility across threads
    (See VolatileDemo.java)
  • Does not provide atomicity of operations
    (See MultiThreadIncrement.java after changing the source to volatile long _count)
  • Note about arrays: An array is an object, holding other objects (or primitives). Making the array volatile does not make the array elements volatile.
• Locking (Synchronized Blocks/Methods)
  • Mutually exclude threads from entering code protected by the same lock
  • Provides atomicity of operations as long as code is protected by the same lock
    (See MultiThreadIncrementLock.java)
  • A synchronized non-static method is equivalent to a method with a synchronized(this) { ... } block that encloses the entire method.
  • A synchronized static method is equivalent to a method with a synchronized(MyClass.class) { ... } block that encloses the entire method.
  • No way to check if a lock is available
  • No timeout
• Wait-Notify-Interrupt
  • Can wait for a certain condition with minimal CPU usage
  • Requires locking: Must use synchronized(o) { ... } before you can call o.wait(); or o.notify(); or o.notifyAll();
  • Can specify timeout: o.wait(milliSeconds)
  • Can be interrupted by other threads: someThread.interrupt();
  • o.wait() can return spuriously, i.e. without proper reason
  • Notifications are not "sticky": If o.notify(); is called before another thread has called o.wait(); , the notification will get lost because it was sent too early.
    (See WaitNotifyEarlyDemo.java)
  • Because of timeout, interruptions, spurious return, early notifications, and o.notifyAll(); , the o.wait(); call should be embedded in a while loop and check that the desired condition is actually true:
    Object lock = new Object(); boolean hasConditionBeenMet = false; // ... public void someMethod() { // ... // check of hasConditionBeenMet must be protected by lock // make sure that you do not release the lock after checking // hasConditionBeenMet and before calling lock.wait(); synchronized(lock) { while(!hasConditionBeenMet) { try { lock.wait(); } catch(InterruptedException e) { // thread was interrupted by another thread } } // hasConditionBeenMet is now true } } public void meetCondition() { synchronized(lock) { hasConditionBeenMet = true; lock.notify(); } }
  • See WaitNotifyDemo.java
  • Make sure that you do not release the lock after checking hasConditionBeenMet and before calling lock.wait(); or another thread might set hasConditionBeenMet to true after a thread has determined it to be false but before waiting. This would cause an "early notification" problem.
    (See WaitNotifySplitDemo.java)
  • Why does hasConditionBeenMet not have to be volatile here? Any changes done under the same lock are visible to other threads:
    

    Thread 1	Thread 2
    acquires lock   changes a non-volatile variable releases lock	waits for lock     acquires lock sees change to variable

  • o.wait(); releases the lock on o, and after being woken up by a o.notify(); or o.notifyAll();, a thread competes for the lock on o again and automatically re-acquires it before continuing after the o.wait();.
    • Note: o.wait(); only releases the lock on o, not on other locks held. If the thread that waits also holds other locks, and the thread that notifies it needs one of those, there will be a deadlock.
      (See WaitLockDrop.java)

• Completion Monitor/Wait One
  • boolean flag, initially false
  • set method, sets flag to true, notify all
  • wait method, wait while flag is false
  • reset method, sets flag to false
  • Should these methods be synchronized?
• Bounded Buffer
  • array of n elements
  • count of elements currently in the buffer
  • put method, waits until count < n, then adds element to buffer
  • get method, waits until count > 0, then removes next element from buffer
  • Should these methods be synchronized?
  • While it does not matter from a concurrency point of view, this buffer should be organized as queue (first in, first out).
• Reader-Writer Locking
  • startRead method, if there are any active writers or waiting writers, increment the number of waiting readers and wait, then decrement the number of waiting readers; increment the number of active readers
  • endRead method, decrement the number of active readers; if there are no active readers, wake up waiting threads (see below)
  • startWrite method, if there are any active readers/writers or waiting writers, increment the number of waiting writers and wait, then decrement the number of waiting writers; increment the number of active writers
  • endWrite method, decrement the number of active writers, wake up waiting threads
  • Waking up threads: There are different ways to implement this.
    • We could just wake all waiting threads up (provided the wait is in a while loop) and let them race to getting the lock; however, this may not be fair, since there is a chance that a thread never make it.
    • It is better to queue the waiting threads up and wake up the first thread. However, if the first thread is a reader, then we could try waking up the next thread; if that's a reader too, they can both run, and so on. Only when we find a writer do we have to stop, because a writer cannot run in parallel with either readers or writers.
  • There are some tricky issues regarding whether the call to wait() should be in a while loop or not. This depends on the choice of how to wake threads up.
  • How do we deal with one thread calling startRead when it has already acquired the read lock?
  • Should these methods be synchronized? What could happen if calling methods are synchronized?

URL: http://www.cs.rice.edu/~javaplt/402/12-spring/lectures/conc2/index.shtml