[concurrency-interest] Offering data to Futures

karlthepagan karlthepagan at gmail.com
Thu May 28 12:21:19 EDT 2009


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> 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
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090528/e7c86a4a/attachment.html>


More information about the Concurrency-interest mailing list