Thanks Jed, that is a much cleaner technique.<div><br></div><div>I&#39;ve started looking at the memory consumption (empirically, 3M iterations per) for the states initial / set / setException:<div>FutureTask(Callable): 64 / 64 / 64</div>
<div>SettableFuture: 72 / 88 / 88</div><div>LockMessageFuture: 88 / 88 / 104</div><div>in a 64-bit vm:</div><div><div>FutureTask(Callable): 112 / 112 / 112</div><div>SettableFuture: 128 / 152 / 152</div><div>LockMessageFuture: 152 / 152 / 176</div>
<div><br></div></div><div><br></div><div>I think that neither SettableFuture&#39;s polymorphic Value holder nor MessageFuture&#39;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.</div>
<div><br></div><div>Going lower is possible, by either directly extending AbstractQueuedSynchronizer (not recommended) or perhaps using intrinsic locks.</div><div><br></div><div>-karl</div><div><br></div><div><div class="gmail_quote">
On Wed, May 27, 2009 at 7:30 PM, Jed Wesley-Smith <span dir="ltr">&lt;<a href="mailto:jed@atlassian.com">jed@atlassian.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
<a href="http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2414" target="_blank">http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2414</a><br>

<br>
cheers,<br><font color="#888888">
jed.</font><div><div></div><div class="h5"><br>
<br>
On 28/05/2009, at 11:24 AM, Jed Wesley-Smith wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a similar class that implements Future but does not take a Runnable/Callable like FutureTask. I realised it didn&#39;t support exceptions (I didn&#39;t need it at the time) so I added that this morning.<br>
<br>
It is considerably simpler in design to your version. It simply uses an AtomicReference and a CountDownLatch to co-ordinate updates and waiting.<br>
<br>
To do the onDone/onFail/onCancel stuff I&#39;d probably use another class that decorates this one and pass handlers rather than using sub-classing.<br>
<br>
<a href="http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2413" target="_blank">http://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/SettableFuture.java?r=2413</a><br>

<br>
cheers,<br>
jed.<br>
<br>
On 26/05/2009, at 10:08 AM, karlthepagan wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a followup to last week&#39;s great discussion of FutureTask.done() callbacks I&#39;d like to ask if anyone else has rolled their own &quot;remote Future&quot; 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.<br>

<br>
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&#39;t usually desirable. For example the Jersey HTTP client API makes use of futures to solve an IO-bound task:<br>

<a href="http://www.nabble.com/HTTP-Client-API--was%3A-Jersey-client-side-API--td22289451.html" target="_blank">http://www.nabble.com/HTTP-Client-API--was%3A-Jersey-client-side-API--td22289451.html</a><br>
<br>
<br>
With that in mind here is an API inspired by a few iterations of this problem:<br>
<br>
public interface MessageFuture&lt;V&gt; extends Future&lt;V&gt; {<br>
   boolean offer(V data);<br>
   boolean offerException(Throwable t);<br>
}<br>
<br>
<br>
I have a possibly naive implementation up on GoogleCode, but feedback is welcome:<br>
<a href="https://karlthepagan.googlecode.com/svn/trunk/MessageFuture/" target="_blank">https://karlthepagan.googlecode.com/svn/trunk/MessageFuture/</a><br>
<br>
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).<br>

<br>
<br>
-karl<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</blockquote>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>