Synchronization and the Collections API
| ||||
| Copyright 1999 Sams Publishing |
| | ||
| | |
| Object API Used for Wait/Notify |
| | |
| The wait/notify mechanism is embedded deep in the heart of Java. Object , the superclass of all classes, has five methods that are the core of the wait/notify mechanism: notify() , notifyAll() , wait() , wait(long) , and wait(long, int) . All classes in Java inherit from Object , so all classes have these public methods available to them. Additionally, none of these methods can be overridden in a subclass as they are all declared final . |
| | |
| notify() |
| | |
| public final native void notify() |
| throws IllegalMonitorStateException // RuntimeException |
| | |
| The notify() method is used by a thread to signal any other threads that might be waiting on the object. If more than one thread is waiting on the object, the thread scheduler will arbitrarily choose exactly one to be notified, and the others will continue to wait. If no threads are currently waiting on the object, notify() has no effect. Before invoking notify() , a thread must get exclusive access to the object-level lock for the object. Unlike wait() , the invocation of notify() does not temporarily release the lock. If the proper lock is not held when notify() is called, an IllegalMonitorStateException is thrown. This exception is a subclass of RuntimeException , so a try-catch construct is not necessary and is rarely used. |
| | |
| notifyAll() |
| | |
| public final native void notifyAll() |
| throws IllegalMonitorStateException // RuntimeException |
| | |
| The notifyAll() method works the same as notify() (see above) with one important exception: When notifyAll() is invoked, all the threads waiting on the object are notified, not just one. The advantage of notifyAll() is that you dont have to be concerned about which one of the waiting threads will be notifiedthey will all be notified. The disadvantage is that it might be wasteful (in terms of processor resources) to notify all the waiting threads if only one will actually be able to proceed. When in doubt, err on the side of safety over speed and use notifyAll() instead of notify() . |
| | |
| wait() |
| | |
| public final void wait() |
| throws InterruptedException, |
| IllegalMonitorStateException // RuntimeException |
| | |
| The wait() method is used to put the current thread to sleep until it is notified or interrupted . Before invoking wait() , a thread must get exclusive access to the object-level lock for the object. Just after entering wait() , the current thread releases the lock. Before returning from wait() , the thread competes with the other threads to reacquire the lock. If the proper lock is not held when wait() is called, an IllegalMonitorStateException is thrown. This exception is a subclass of RuntimeException , so a try-catch construct is not necessary and is rarely used. |
| | |
| If the waiting thread is interrupted, it competes to reacquire the lock and throws an InterruptedException from within wait() . This exception is not a subclass of RuntimeException , so a try-catch construct is required. |
| | |
| wait(long) |
| | |
| public final native void wait(long msTimeout) |
| throws InterruptedException, |
| IllegalMonitorStateException, // RuntimeException |
| IllegalArgumentException // RuntimeException |
| | |
| The wait(long) method is used to put the current thread to sleep until it is notified, interrupted, or the specified timeout elapses. Other than the timeout, wait(long) behaves the same as wait() (see above). The argument msTimeout specifies the maximum number of milliseconds that the thread should wait for notification. If msTimeout is , the thread will never time out (just like wait() ). If the argument is less than , an IllegalArgumentException will be thrown. IllegalArgumentException is a subclass of RuntimeException , so a try-catch block is not required and is rarely used. |
| | |
| If the specified number of milliseconds elapses before the waiting thread is notified or interrupted, it competes to reacquire the lock and returns from wait(long) . There is no way for the caller to determine whether a notification or a timeout occurred because no information ( void ) is returned from wait(long) . |
| | |
| wait(long, int) |
| | |
| public final void wait(long msTimeout, int nanoSec) |
| throws InterruptedException, |
| IllegalMonitorStateException, // RuntimeException |
| IllegalArgumentException // RuntimeException |
| | |
| The wait(long, int) method works just like wait(long, int) (see above) with the exception that nanoseconds can be added to the timeout value. The argument nanoSec is added to msTimeout to determine the total amount of time that the thread will wait for notification before returning. A nanosecond is one-billionth of a second ( 10E-9 ), and most common implementations of the Java VM dont truly support this fine a resolution of time. For this reason, the use of the method is currently quite rare. |
| |  | ||
| Toc | |||
