[concurrency-interest] Lock free caches

Mike Quilleash mike.quilleash at subexazure.com
Thu Apr 12 15:38:47 EDT 2007


Good point.  Revised below.


        // get the future result
        // if two threads enter around the same time one will "win" and
run the future
        // the other will wait here for the future result to become
available
        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

            // make sure to only remove if the input key is still
referencing the same future
            // there is an edge case where if more than one thread calls
future.get() and catches
            // this exception the first will remove the entry from the
map which will allow other
            // threads to recompute and add an entry to the map.  the
second failed thread may then
            // come here and remove the entry from the map again even
though the future is "stale"
            if ( retryFailedCompute )
                map.remove( input, future );

            throw new RuntimeException( e.getCause() );
        }
-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Joe
Bowbeer
Sent: 12 April 2007 20:05
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Lock free caches

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.
> >
>
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


 This e-mail is bound by the terms and conditions described at http://www.subexazure.com/mail-disclaimer.html




More information about the Concurrency-interest mailing list