[concurrency-interest] When do you use wait/notify?

Ian Griffiths ian.griffiths@yellow-b.com
Sun, 25 Jan 2004 10:24:01 +0100

Hi Joseph,

I agree that the interfaces are very similar. In fact, the spec for 
java.util.concurrent.Future is similar. Where I feel less happy is the 
cancel method, the JavaDoc says:

Cancellation is performed by the cancel method. Additional methods are 
provided to determine if the task completed normally or was cancelled. 
Once a computation has completed, the computation cannot be cancelled. 
If you would like to use a Future for the sake of cancellability but 
not provide a usable result, you can declare types of the form Future<?
> and return null as a result of the underlying task.

This gives me the impression that the essence of the Future is the 
asynchronous task that produces the result (and can be cancelled) 
rather than the result itself.

This feeling is reinforced when looking at the constructors of 
FutureTask which REQUIRES either a Runnable or a Callable parameter. 

In my case, I have one low-priority task which will eventually create a 
number of futures (i.e. not one task per Future as some results come in 
groups at the end of a calculation or are grouped in one XML file that 
is read at some point). 

However, as the application communicates with other processes, it 
receives values that have already been calculated on other machines. 
So, rather than discard them after use, it sets the appropriate Futures 
thus provoking notification of any threads that may have been waiting 
for a reply and freeing the base task of having to calculate its value.

There is also a mechanism for threads that are in a hurry and can't 
wait long for them to produce the values in a higher-priority thread 
which obviously also sets the Future for others to use.

In my case, I am unhappy with the cancel method as the future has no 
idea which task is going to calculate its contents and most tasks 
produce more than one Future, so killing them would stop other 
(necessary) values from being calculated!

Converting the system so that there is one task per Future would be 
incredibly inefficient (and may well swamp the VM with simultaneous 

I agree that I could easily create a class that implements the 
java.util.concurrency.Future interface and has a no-parameter 
constructor (and doesn't cancel anything). However, to do that would 
involve using cals to wait() and notifyAll(). Which was the question 
Doug Lea was asking.

Best Regards


-----Original Message-----
From: "Joseph Bowbeer" <jozart@blarg.net>
To: <concurrency-interest@altair.cs.oswego.edu>
Date: Sun, 25 Jan 2004 00:40:48 -0800
Subject: Re: [concurrency-interest] When do you use wait/notify?

> Ian,
> In what ways is the proposed java.util.concurrent.Future interface
> deficient?
> Comparing jet Future with juc Future,
> 1. I see that they both have get methods.
> 2. jet's isSet method looks similar to juc's isDone.
> 3. A notable difference is that jet provides a set method in the
> interface,
> whereas juc only provides a set method in concrete impls such as
> FutureTask.
> ----- Original Message ----- 
> From: "Ian Griffiths" <ian.griffiths@yellow-b.com>
> To: <concurrency-interest@altair.cs.oswego.edu>
> Sent: Sunday, January 25, 2004 12:15 AM
> Subject: [concurrency-interest] When do you use wait/notify?
> I am new to this list and should like to apologize if something has
> escaped my attention.
> I still use wait notify to handle a very simple Future
> implementation.
> In my application, I have a number of objects I may be asked to
> provide
> and have a very low priority thread that will instantiate them all
> over
> time.
> However many of the objects may also be produced as by-products of
> other tasks that get them from other, parallel, processes or that
> create them in response to an urgent request. thus sparing my basic
> thread the tiresome job of re-calculating them from scratch.
> To do this I use a very implementation of a Future:
> package jet.util.concurrency;
> /**
>  * A Future is an object that encapsulates a value that may
>  * only appear at a later date.
>  */
> public interface Future {
> /**
> * Method getValue.
> * @return Object the value of the Future
> * @throws InterruptedException If the wait is interrupted
> */
>     public Object getValue() throws InterruptedException;
> /**
> * Method isSet Says whether a value has been set.
> * @return boolean true if a value has been set.
> */
>     public boolean isSet();
> /**
> * Method setValue.Set the value for this future
> * @param value The value to be set.
> */
>     public void setValue(Object value);
> }
> The important point is that the Future is not linked to any specific
> task, as I do not know how it will be obtained when I create the
> Future.
> Best Regards.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest