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

Ian Griffiths ian.griffiths@yellow-b.com
Sun, 25 Jan 2004 15:39:23 +0100


Hi Doug,

Thanks for your reply. I was worried I had missed something important 
there and didn't know where to find it!

I feel that it would be usefull in a future (forgive the pun) version 
of the package to have a class that just contains a Future object (say 
BasicFuture) that is not associated to a task but that could be 
extended in a meaningfull way by developers. That would hide the nitty-
gritty of wait()s and notify()s and would allow you to do the fine 
tuning as the JDK develops (although in this case, there doesn't seem 
to be much to tune!).

Best Regards

Ian

-----Original Message-----
From: Doug Lea <dl@cs.oswego.edu>
To: "Ian Griffiths" <ian.griffiths@yellow-b.com>
Cc: concurrency-interest@altair.cs.oswego.edu
Date: Sun, 25 Jan 2004 09:05:14 -0500
Subject: Re: [concurrency-interest] When do you use wait/notify?

> > 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!
> 
> (We in the expert group considered this issue several times: Some
> applications cannot live without cancellability, and some cannot live
> with it. But it wouldn't work out at all well to define parallel APIs
> differing only with respect to this. The compromise was to allow the
> cancel method to return false if it cannot, or just doesn't want to
> cancel the task. So, "return false" is a valid implementation.)
> 
> > 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(). 
> 
> Right. That's a great example; thanks!  While we set up interfaces to
> allow such variants in concrete Future classes, we don't, and can't,
> provide all of the support that you might need to build all possible
> custom implementations.
> 
> 
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest