[concurrency-interest] High performance Future aggregation - polling vs latching

Outside - Karl's ACM kpauls at acm.org
Mon Aug 7 20:53:58 EDT 2006

I think I have an issue with Java 5 & 6's Future interface and the FutureTask
implementation, but I'm starting to think that it could be inappropriate to
use Future for the problem at hand. I could be stumbling over some of the
finer points of the concurrency library.



Let's say that you wanted to aggregate a number of possible available results
from a set of heterogeneous Futures with an aggregate time limit. After
marking the start time my implementation would first iterate through the
futures aggregating all complete futures. Then I would calculate the time
remaining and "spend" some fraction of that remaining time to wait for one of
the futures and repeat gathering up the completed futures.


The only way to poll a Future for its result indicates a timeout by throwing
an exception. Specifically:  Future.get(long timeout, TimeUnit unit)... So
every time I wait for a future without a result I experience a performance
hit from generating the exception. If implemented an additional "await"
method with a timeout parameter would not incur that expense. This method
would return a boolean indicating the Future.isDone result. The method
signature would look something like this: boolean await(long timeout,
TimeUnit unit).



It occurred to me that another method to wait on a set of futures would be to
create a CountDownLatch and wrap the Callable(s) in a Callable implementation
which counts down the latch. However, using the count down method I don't see
how to hook a new set of futures to a latch when they are already submitted
to the executor.


Even if an "await" method were provided on the Future interface it would not
be the most effective way to return a set of results as soon as some number
of them were ready: for instance attempting to return 5 of 10 completed
futures without a latch would likely result in some time wasted blocked on an
await call for a Future which would not complete before the others.



Is there a better way to aggregate futures or should I investigate a
different library for this kind of problem?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060807/02c6227b/attachment.html 

More information about the Concurrency-interest mailing list