[concurrency-interest] Lock free caches

Joe Bowbeer joe.bowbeer at gmail.com
Thu Apr 12 15:05:25 EDT 2007


worse yet, a thread can remove a successfully retried computation.
removeIfPresent can help there though.

On 4/12/07, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> Note that several callers may return the previously reported error
> before one of the threads removes the failed Future from the map.
>
> Btw, the list archives contain a long discussion about error handling
> that's worth checking, too.
>
> On 4/12/07, Mike Quilleash <mike.quilleash at subexazure.com> wrote:
> > As an enhancment to the implementation using FutureTask I think you can
> make it a bit more fail-safe by removing an entry from the map if the
> computation throws an exception.
> >
> >         try
> >         {
> >             return future.get();
> >         }
> >         catch ( InterruptedException e )
> >         {
> >             // re-interrupt
> >             Thread.currentThread().interrupt();
> >
> >             throw new RuntimeException( e );
> >         }
> >         catch ( ExecutionException e )
> >         {
> >             // remove the future from the map as it is now broken - next
> thread to request
> >             // this input will attempt to recompute the value
> >             if ( retryFailedCompute )
> >                 map.remove( input );
> >
> >             throw new RuntimeException( e.getCause() );
> >         }
> >
> > So on an ExecutionException, originally thrown from doCompute(), the
> "dead" future will be removed from the map so the next request will cause a
> retry (depending on the retryFailedCompute flag).  This might be useful for
> operations that can-but-usually-don't fail.  Threads already passed the
> initial map.get() will still throw the exception but subsequent ones stand a
> chance of succeeding.  When the computation should never fail and is broken
> if it does fail then setting the retryFailedCompute to false will cause the
> same exception to be thrown for every thread requesting the value.
> >
> > Further enhancements could involve some sort of retry policy to handle
> failure and decide on retrying vs exception and anything else like wait time
> between retries etc.
> >
>


More information about the Concurrency-interest mailing list