Home  Synchronization and concurrency  wait/notify  final  volatile  synchronized keyword  Java threading  Deadlock (and avoiding it)  Java 5: ConcurrentHashMap  Atomic variables  Explicit locks  Queues  Semaphores  CountDownLatch  CyclicBarrier

Using wait(), notify() and notifyAll() in Java (ctd)

On the previous page, we showed how to create a very simple connection pool, in which a thread could call a getConnection() method. If no connection was currently available, this method would wait for one to become available. A downside of it is that if no connection became avaialable, the method would essentially wait forever. A functionality that we often want in this case is to say "wait for up to n seconds, else give up". And we can get that with a timed wait.

Timed waits

In a timed wait, we pass in a parameter to the wait() method specifying how long we want to wait for. Up to Java 1.4, the maximum wait time is specified in milliseconds. So, the following would wait for up to 3 seconds:

// Wait for up to 3 seconds for a connection
connections.wait(3000);

From Java 5 onwards, an extra parameter allows you to specify the wait time down to the nanosecond. In reality, no mainstream operating system provides that level of granularity (to within a few milliseconds, or multiples of the interrupt period– often 10 milliseconds– is typical). But in principle at least, some real-time operating systems may provide more granularity than the millisecond.

So, when we're woken up, how do we know if it was because we were notified or because we timed out? The answer is, we don't know why we were woken up. Just as actually we don't even with the non-timed wait (in principle, the OS could just wake us up for a laugh1). So in a case such as this, if we're woken up and there is no connection in the list, we need to explicitly time how long we were waiting (e.g. via System.currentTimeMillis()) and decide whether to give up or wait again.

Next...

On the next pages we look at:


Notes:
1. One reason that this might happen would be if an OS only implemented 'notify all' functionality, and not single-thread notify. In this case, a JVM might be forced to implement notify() as a 'notify all' action. According to the spec, this would be a legal JVM implementation. (In reality, I believe all mainstream OS's provide both calls.)

Article written by Neil Coffey (@BitterCoffey).

Software

 LetterMeister (word puzzle game for iPhone)
 Currency Quoter (currency converter/predictor)
 French Vocab Games for iPhone/iPad
 Vocabularium: create Spanish vocab podcasts


Java programming articles and tutorials on this site are written by Neil Coffey (@BitterCoffey). Suggestions are always welcome if you wish to suggest topics for Java tutorials or programming articles, or if you simply have a programming question that you would like to see answered on this site. Most topics will be considered. But in particular, the site aims to provide tutorials and information on topics that aren't well covered elsewhere, or on Java performance information that is poorly described or understood. Suggestions may be made via the Javamex blog (see the site's front page for details).
Copyright © Neil Coffey 2015. All rights reserved.