Coursera: concurrent programming
Thread lifecycle
wait() method
Simply put, calling wait() forces the current thread to wait until some other thread invokes notify() or notifyAll() on the same object. For this, the current thread must own the object's monitor. According to Javadocs, this can happen in the following ways:
when we've executed synchronized instance method for the given object
when we've executed the body of a synchronized block on the given object
by executing synchronized static methods for objects of type Class
WAIT() causes the current thread to place itself in the wait set for this object and then to give away any and all synchronization claims on this object. Note that only the locks on this object are given away; any other objects on which the current thread may be synchronized remain locked while the thread waits.
notify() and notifyAll()
For all threads waiting on this object's monitor (by using any one of the wait() methods), the method notify() notifies any one of them to wake up arbitrarily. The choice of exactly which thread to wake is nondeterministic and depends upon the implementation.
Since notify() wakes up a single random thread, we can use it to implement mutually exclusive locking where threads are doing similar tasks. But in most cases, it would be more viable to implement notifyAll().
Critical section
Critical sections and the isolated construct can help concurrent threads manage their accesses to shared resources, at a higher level than just using locks. When programming with threads, it is well known that the following situation is defined to be a data race error — when two accesses on the same shared location can potentially execute in parallel, with least one access being a write. However, there are many cases in practice when two tasks may legitimately need to perform concurrent accesses to shared locations, as in the bank transfer example.
Optimistic concurrency
Last updated