The wait methods The notify methods

return; } public synchronized void checkForNegativeAMountMoney amount throws NegativeAmountException { ... } This will work. Whats more, the thread executing makeDeposit will keep the lock until makeDeposit is exited. Javas locking mechanism keeps a reference count of the number of times a lock is acquired by a particular thread and only releases the lock when the count returns to 0.

11.4.2 Thread Manipulation Methods Defined on Object

In addition to the synchronized keyword, the core Java libraries include a number of methods defined on Object to help manage locks and coordinate the actions of multiple threads. These methods are: public void notify public void notifyAll public void wait public void waitlong timeout public void waitlong timeout, int nanoseconds All of these methods require the code calling them to already have the lock associated with the instance on which they are being called. For example: foo.wait ; will throw an exception unless the call is made by a thread that currently owns the lock associated with foo . This is because these methods are used for interthread communications based on an event model. This event model is easily described: some threads wait for an event; other threads notify the waiting threads that the event has occurred.

11.4.2.1 The wait methods

With the wait methods, a thread waits to be notified that an event has occurred. In the no- argument version of wait , a thread can wait forever. Furthermore, the wait methods actually relinquish the lock and proceed to block. That is, the following code will block immediately after the wait and not execute println until later, when the thread resumes well discuss how this happens later in the chapter: synchronizedthis { wait ; blocked System.out.printlnWe dont get here right away; } In the versions of wait that take arguments, the thread will wait for, at most, the duration of the arguments. After which, it will attempt to reaquire the lock it gave up when it called wait , and continue processing. In either case, whether because it was notified or because time expired, the thread will then attempt to reacquire the lock; because it is inside a synchronized block, it needs to acquire the lock to continue processing. This means that, after waiting, the thread will block until the lock becomes available, just as if it had recently executed synchronized . The wait methods surrender only the locks associated with the instances on which they called wait . If a thread has the instances on which they called wait . If a thread has locks associated with 14 different instances and calls wait on one of those instances, the sleeping thread still holds on to the other 13 locks.

11.4.2.2 The notify methods

With the notify methods, a thread sends a simple event Wake up to one or more threads that have previously called one of the wait methods on the same instance. notify wakes up a single waiting thread; notifyAll wakes up all waiting threads. All of the awakened threads immediately block because the thread that called the notify method still holds the lock associated with the instance. Until the thread that called notify relinquishes the lock, the awakened threads will not be able to continue processing. Notify Versus NotifyAll People frequently wonder when to use notify and when to use notifyAll . Both are used to announce that an event has occurred to waiting threads. Since notify wakes up a single waiting thread, and notifyAll wakes up all the waiting threads most of which immediately block, its clearly more efficient to use notify . However, there are situations when notifyAll is absolutely the correct choice. One example is when there is more than one type of thread that needs to know about an event. For example, in a distributed chat room application, we might make the following design decisions: 1. There is a single centralized WhiteBoard object, which contains the transcript of the conversation. 2. Every remote participant is assigned a thread that sends new lines of text. 3. Posting a new piece of text involves locking the whiteboard, adding the text to the whiteboard and then calling notifyAll . Each thread grabs the change and sends it out. Another example occurs when the same lock is used to signal more than one type of event and different types of events are handled by different types of waiting threads. For example, in a stockticker application, we may not want lots of information to pile up, waiting to be sent. One possible design uses a fixed-length queue to control communication. This involves the following design decisions: • There is a fixed-length queue and two threads. One thread sends messages out to the recipient, pulling them off the queue. Another thread gets messages from the sender and puts them on the queue. • Because the queue is fixed-length, however, both threads also need to wait on the queue when they get ahead. The client thread will wait for messages to come into the queue. The server thread will wait for messages to be sent, so that more space is available on the queue. • There is only one lock, but there are two events message put in queue and message removed from queue, each intended for a different thread. Therefore, notifyAll must be used. But, even beyond the cases when notifyAll is absolutely required, theres a simple fact that causes many programmers to use it as the default: at any point where notify can be used, notifyAll can also be used. You may need to add a check or two, but thats it; at worst, the program will be a little less efficient. On the other hand, if notifyAll is required, and you use notify , the program will simply be incorrect, and theres usually no way to fix it other than to use notifyAll .This line of reasoning leads many programmers to simply use notifyAll whenever they need to alert a waiting thread.

11.4.3 Classes