[concurrency-interest] Offering data to Futures

Jed Wesley-Smith jed at atlassian.com
Thu May 28 20:16:57 EDT 2009


Thanks Karl.

Is the memory consumption so important in this case? I would have 
thought that generally these objects have a medium sized life and you 
would generally discard them once get() returns.

If it is, there would definitely be a couple of ways to put them on a 
diet at the expense of implementation complexity. Additionally, the 
producer in both the FutureTask and SettableFuture is lock-free, 
maintaining that would be difficult.

There are a number of techniques I can think of to shave off some bytes 
but they would all negatively affect readability and maintainability. 
And Doug has conniptions if you use Unsafe directly :-)

cheers,
jed.

karlthepagan wrote:
> Thanks Jed, that is a much cleaner technique.
>
> I've started looking at the memory consumption (empirically, 3M 
> iterations per) for the states initial / set / setException:
> FutureTask(Callable): 64 / 64 / 64
> SettableFuture: 72 / 88 / 88
> LockMessageFuture: 88 / 88 / 104
> in a 64-bit vm:
> FutureTask(Callable): 112 / 112 / 112
> SettableFuture: 128 / 152 / 152
> LockMessageFuture: 152 / 152 / 176
>
>
> I think that neither SettableFuture's polymorphic Value holder nor 
> MessageFuture's marker objects would be as memory efficient as adding 
> a discrete synchronizer state for setting exceptions using the 
> implementation pattern of FutureTask. That could produce a 48 (88) 
> byte object.
>
> Going lower is possible, by either directly extending 
> AbstractQueuedSynchronizer (not recommended) or perhaps using 
> intrinsic locks.
>
> -karl
>
> On Wed, May 27, 2009 at 7:30 PM, Jed Wesley-Smith <jed at atlassian.com 
> <mailto:jed at atlassian.com>> wrote:
>
>     I realised if I am offering up that class up for public
>     consumption I should probably support cancellation. I also managed
>     to shave a reference off for the byte conscious.
>
>     http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2414
>
>     cheers,
>     jed.
>
>
>     On 28/05/2009, at 11:24 AM, Jed Wesley-Smith wrote:
>
>         I have a similar class that implements Future but does not
>         take a Runnable/Callable like FutureTask. I realised it didn't
>         support exceptions (I didn't need it at the time) so I added
>         that this morning.
>
>         It is considerably simpler in design to your version. It
>         simply uses an AtomicReference and a CountDownLatch to
>         co-ordinate updates and waiting.
>
>         To do the onDone/onFail/onCancel stuff I'd probably use
>         another class that decorates this one and pass handlers rather
>         than using sub-classing.
>
>         http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2413
>
>         cheers,
>         jed.
>
>         On 26/05/2009, at 10:08 AM, karlthepagan wrote:
>
>             As a followup to last week's great discussion of
>             FutureTask.done() callbacks I'd like to ask if anyone else
>             has rolled their own "remote Future" implementation or
>             something which interfaces with a messaging library? I
>             found one attribute of FutureTask.Sync is that it protects
>             innerSet and innerSetException from being set outside of
>             innerRun so as far as I imagined it cannot be extend to
>             provide a receiver for messages.
>
>             I find the Future API so comfortable that I wanted to
>             apply it to other IO-bound and remote tasks rather than
>             simply CPU-bound tasks, but consuming a thread per request
>             isn't usually desirable. For example the Jersey HTTP
>             client API makes use of futures to solve an IO-bound task:
>             http://www.nabble.com/HTTP-Client-API--was%3A-Jersey-client-side-API--td22289451.html
>
>
>             With that in mind here is an API inspired by a few
>             iterations of this problem:
>
>             public interface MessageFuture<V> extends Future<V> {
>               boolean offer(V data);
>               boolean offerException(Throwable t);
>             }
>
>
>             I have a possibly naive implementation up on GoogleCode,
>             but feedback is welcome:
>             https://karlthepagan.googlecode.com/svn/trunk/MessageFuture/
>
>             After providing something that could meet the needs of
>             Jersey and/or Grizzly http-client I would like to move
>             this in the direction of simplifying the interface to
>             message-based systems without creating additional message
>             handles when they are not solicited (i.e. submit() would
>             create a Future task but execute() would not).
>
>
>             -karl
>             _______________________________________________
>             Concurrency-interest mailing list
>             Concurrency-interest at cs.oswego.edu
>             <mailto:Concurrency-interest at cs.oswego.edu>
>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>         _______________________________________________
>         Concurrency-interest mailing list
>         Concurrency-interest at cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>



More information about the Concurrency-interest mailing list