High performance Future aggregation - polling vs latching

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

High performance Future aggregation - polling vs latching

Outside - Karl's ACM

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?

 

 

-karl


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: High performance Future aggregation - polling vs latching

Joe Bowbeer
On 8/7/06, Outside - Karl's ACM <[hidden email]> wrote:
>
> 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.
>

Have you ruled out ExecutorCompletionService?

Another technique would be to implement custom futures that notify you
upon completion.  Override the done method to implement this feature.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: High performance Future aggregation - polling vs latching

Brian Goetz
In reply to this post by Outside - Karl's ACM
> Is there a better way to aggregate futures or should I investigate a
> different library for this kind of problem?

Take a look at ExecutorCompletionService.  Also see the explanation of
how it works and how you can build the same thing yourself in JCiP 6.3.5.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: High performance Future aggregation - polling vs latching

Gregg Wonderly-2
In reply to this post by Outside - Karl's ACM


Outside - Karl's ACM wrote:
> 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.

How busy will the JVM actually be, how long are these 'waits' and how many will
be running at the same time?  I'm not so sure that the exception generation
overhead (microseconds of CPU perhaps) is going to unduely impact your JVM
performance.

Also, have you looked at JavaSpaces?  It is really good at distributing work
loads and allowing you to scale up such applications by just adding more
computers as you need.

Gregg Wonderly
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: High performance Future aggregation - polling vs latching

Outside - Karl's ACM
In reply to this post by Outside - Karl's ACM
> -----Original Message-----
> From: Gregg Wonderly [mailto:[hidden email]]
> Sent: Monday, August 07, 2006 8:33 PM
>
> How busy will the JVM actually be, how long are these 'waits' and how many
> will
> be running at the same time?  I'm not so sure that the exception
> generation
> overhead (microseconds of CPU perhaps) is going to unduely impact your JVM
> performance.

I'm more concerned about the memory cost.

I did put together a little impl of each method and using the
ExecutorCompletionService is much cleaner than polling and does not lend
itself to implementation errors (such as a poor wait strategy).

I'm considering JavaSpaces for future projects.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest