[concurrency-interest] When do you use wait/notify?
Sun, 25 Jan 2004 15:39:23 +0100
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!).
From: Doug Lea <email@example.com>
To: "Ian Griffiths" <firstname.lastname@example.org>
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
> > 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
> > 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.
> Concurrency-interest mailing list