[concurrency-interest] Composing multiple tasks into a single Future/FutureTask

Joe Bowbeer joe.bowbeer at gmail.com
Tue Apr 17 20:36:33 EDT 2012


FutureTask has a protected set() method which completes the future.
 FutureTask.get blocks until set is called.

Instead of having your future results depend on the fsync task, I would
hand your futures to the fsync task so that it can complete them when the
writes are durable -- by calling their (public) set method, or a custom
method.

I'm picturing your custom Future results as little state machines that
implement a setState(state) method.  The final transition is when fsync
sets their state to WRITTEN; at this point the custom Future sets its
result and completes.

Joe

On Tue, Apr 17, 2012 at 8:39 AM, Ariel Weisberg wrote:

> Hi all,
>
> I have been looking for the right way to build an API that returns a
> Future that is composed of tasks that will be performed in multiple
> stages, potentially from more than one thread.
>
> My use cases is a disk based persistence store. The initial put API
> call creates a task that compresses and checksums the payload. The
> resulting Future is bound in a Runnable and submitted to a single
> thread ExecutorService that timestamps the entry and appends it to a
> file and it is the Future of the second task that is currently returned
> by the API.
>
>  The trick is that the Future that is returned by the put call should
>  not complete until the write is durable. Writes are made durable by
>  periodically invoking fsync from a dedicated thread or by rotating
>  write threads as each blocks on fsync/force. This allows for group
>  commit at an interval the IO device can handle without killing
>  throughput.
>
> Ideally I could create a FutureTask that is composed of several other
> Futures, some of which will not exist when the FutureTask is initially
> created and returned by the API. I do know how many dependencies there
> will be
> expected up front.
>
> If I had such a thing I would create a task to do the fsync and add it
> as the last dependency to every Future read by the put API call.
>
> This would be a lot easier if I were willing to have many threads
> standing around blocking on Futures, but that rubs me the wrong way. It
> isn't fun to jstack and see all the noise.
>
> I suspect that there is something in Guava
> com.google.common.util.concurrent.Futures to handle this case, but it
> isn't jumping out at me.
>
> Thanks,
> Ariel Weisberg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120417/f8543694/attachment.html>


More information about the Concurrency-interest mailing list