Resetting FutureTask

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Resetting FutureTask

Tutika Chakravarthy
Hi,
I have a small question about the popular Memoize
example
code snippet:
  public class Memoize<A, V> implements Computable<A,
V>
{
     public Memoize(Computable<A, V> c) {
         this.c = c;
     }
     public V compute(final A arg) throws Exception {
         Future<V> f = cache.get(arg);
         if (f == null) {
             Callable<V> eval = new Callable<V>() {
                 public V call() throws Exception {
                     return c.compute(arg);
                 }
             };
             FutureTask<V> ft = new
FutureTask<V>(eval);
             f = cache.putIfAbsent(arg, ft);
             if (f == null) { f = ft; ft.run(); }
         }
         return f.get();
     }
     private final ConcurrentMap<A, Future<V>> cache =
         new ConcurrentHashMap<A, Future<V>>();
     private final Computable<A, V> c;
}

My questions is, if call() method in Callable instance
throws Exception , How can I reset the FutureTask?

I am trying to put some code around "f.get()" like

try{
f.get()

}catch(ExecutionException e)
{
cache.remove(arg,f);

}

But will this solve the problem of reseting the
FutureTask?

If one thread gets an exception in call() method,I am
trying to avoid other threads getting the same
exception.


Tutika


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Resetting FutureTask

Joe Bowbeer
When the FutureTask completes it latches onto  a value or an
exception, and it's not designed to let go (i.e., reset).

Either your app needs to be able to deal with failures of this nature.
 Or your Callable needs to be designed not to fail -- using its own
retry mechanism, for example, or returing a special FAILURE value.
(If your value source is anything like a database, I suggest you write
your app to deal with the failures -- or timeouts, at least.)

A third approach would be to add a custom Future to the cache, create
and schedule separate FutureTask(s) to produce a value, and only set
the cached Future's value after a good value has been obtained from
one of the FutureTasks.  This approach might appear to "hang" in the
worst case.  Doug sketches the custom Future part in the FAQ he sent
recently.

--Joe

On 5/23/06, Tutika Chakravarthy <[hidden email]> wrote:

> Hi,
> I have a small question about the popular Memoize
> example
> code snippet:
>   public class Memoize<A, V> implements Computable<A,
> V>
> {
>      public Memoize(Computable<A, V> c) {
>          this.c = c;
>      }
>      public V compute(final A arg) throws Exception {
>          Future<V> f = cache.get(arg);
>          if (f == null) {
>              Callable<V> eval = new Callable<V>() {
>                  public V call() throws Exception {
>                      return c.compute(arg);
>                  }
>              };
>              FutureTask<V> ft = new
> FutureTask<V>(eval);
>              f = cache.putIfAbsent(arg, ft);
>              if (f == null) { f = ft; ft.run(); }
>          }
>          return f.get();
>      }
>      private final ConcurrentMap<A, Future<V>> cache =
>          new ConcurrentHashMap<A, Future<V>>();
>      private final Computable<A, V> c;
> }
>
> My questions is, if call() method in Callable instance
> throws Exception , How can I reset the FutureTask?
>
> I am trying to put some code around "f.get()" like
>
> try{
> f.get()
>
> }catch(ExecutionException e)
> {
> cache.remove(arg,f);
>
> }
>
> But will this solve the problem of reseting the
> FutureTask?
>
> If one thread gets an exception in call() method,I am
> trying to avoid other threads getting the same
> exception.
>
>
> Tutika
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Resetting FutureTask

Joe Bowbeer
More to my answer below.

> On 5/23/06, Tutika Chakravarthy <[hidden email]> wrote:
> I am trying to put some code around "f.get()" like
>
> try{
>     f.get()
> } catch (ExecutionException ex) {
>     cache.remove(arg);
> }
>

This would be another approach.  I would code it more like:

  try{
      return f.get()
  } catch (ExecutionException ex) {
      cache.remove(arg);
      throw ex;
  }

In this case, the calling thread and all threads currently waiting on
this result would see an exception, but future callers would have a
chance to insert a good value in the cache.

--Joe


On 5/23/06, Joe Bowbeer <[hidden email]> wrote:

> When the FutureTask completes it latches onto  a value or an
> exception, and it's not designed to let go (i.e., reset).
>
> Either your app needs to be able to deal with failures of this nature.
>  Or your Callable needs to be designed not to fail -- using its own
> retry mechanism, for example, or returing a special FAILURE value.
> (If your value source is anything like a database, I suggest you write
> your app to deal with the failures -- or timeouts, at least.)
>
> A third approach would be to add a custom Future to the cache, create
> and schedule separate FutureTask(s) to produce a value, and only set
> the cached Future's value after a good value has been obtained from
> one of the FutureTasks.  This approach might appear to "hang" in the
> worst case.  Doug sketches the custom Future part in the FAQ he sent
> recently.
>
> --Joe
>
> On 5/23/06, Tutika Chakravarthy <[hidden email]> wrote:
> > Hi,
> > I have a small question about the popular Memoize
> > example
> > code snippet:
> >   public class Memoize<A, V> implements Computable<A,
> > V>
> > {
> >      public Memoize(Computable<A, V> c) {
> >          this.c = c;
> >      }
> >      public V compute(final A arg) throws Exception {
> >          Future<V> f = cache.get(arg);
> >          if (f == null) {
> >              Callable<V> eval = new Callable<V>() {
> >                  public V call() throws Exception {
> >                      return c.compute(arg);
> >                  }
> >              };
> >              FutureTask<V> ft = new
> > FutureTask<V>(eval);
> >              f = cache.putIfAbsent(arg, ft);
> >              if (f == null) { f = ft; ft.run(); }
> >          }
> >          return f.get();
> >      }
> >      private final ConcurrentMap<A, Future<V>> cache =
> >          new ConcurrentHashMap<A, Future<V>>();
> >      private final Computable<A, V> c;
> > }
> >
> > My questions is, if call() method in Callable instance
> > throws Exception , How can I reset the FutureTask?
> >
> > I am trying to put some code around "f.get()" like
> >
> > try{
> > f.get()
> >
> > }catch(ExecutionException e)
> > {
> > cache.remove(arg,f);
> >
> > }
> >
> > But will this solve the problem of reseting the
> > FutureTask?
> >
> > If one thread gets an exception in call() method,I am
> > trying to avoid other threads getting the same
> > exception.
> >
> >
> > Tutika
> >
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

about Volatile reads/writes

yangjs
In reply to this post by Tutika Chakravarthy
hi,all
 
javaone 2006 session about The Java¬ô Technology Memory Model:the building block of concurrency
how to explain the follow sentence?
 
Volatile reads/writes cannot be reordered
Reads/writes become acquire/release pairs
 
 
 
 
thx
 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: about Volatile reads/writes

Jeremy Manson
yangjs wrote:
> how to explain the follow sentence?
>
> Volatile reads/writes cannot be reordered
> Reads/writes become acquire/release pairs

As the speaker for that particular slide, I hate to seem flip, but it
means what it says.

1) Volatile accesses cannot appear to have been reordered with each
other.  For example, let's say I have two volatile boolean fields, v1
and v2, and the following code running in one thread:

v1 = true;
v2 = true;

And the following code running in another:

if (v2)
   assert v1;

The assertion is not allowed to fail.  If the accesses in the first
thread were reordered, then the assertion could fail - the second thread
could see v2 being true before it sees v1 being true.

2) A read of a volatile acts like an acquire, and a write to a volatile
acts like a release.  There is therefore a happens-before relationship
between a write to a volatile and a read of a volatile.  In the example
above, this implies that the assertion can't fail even if v1 is not
volatile, as long as v2 is volatile.

I suggest you read the JSR-133 FAQ for more information:

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

Especially the sections on what synchronization does and what volatile
does.  Better still, run over to amazon.com and get yourself a copy of
Java Concurrency in Practice.


                                        Jeremy
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest