Future and Callable Doubt

[Mohit Chauhan]

Hi ,

I am new to Concurrent Multithreading in java .Some of my doubts may seem minor .Actually i have doubts related to internal working of Futures and Callable.

We use Future.get() to get the call() results . Suppose we have multiple threads in our program where suppose First thread is taking 15-20 min to execute . then in that case the other thread which is trying to execute does Future.get() will have to wait for first one to complete . Because in Future.get() documentation it is written for get() documentation [Waits if necessary for the computation to complete, and then retrieves its result.] .

So I am confused with this statement that wait will happen across threads and if its the case then how this Future and Callable adding value ??

[Marco Ehrentreich]

Hi Mohit,

your understanding of Future.get() is correct. Calling get() will block your current thread until the computation is finished (additionally you can specify a timeout). So obviously it wouldn't give you any advantages to make some computations in a background thread and block your main thread by waiting on the result from the background thread. This would be similar to simply doing all the work directly in your main thread.

But it really depends on the problem you are trying to solve what a good solution could look like. Java offers a lot more helpful classes and tools for concurrent applications. For example an

ExecutorService

can be very helpful if you can break down your problem at hand into many smaller problems which can be solved in parallel. But of course this will only work if the smaller problems don't depend on each other and so.

Unfortunately this topic is way too complicated to discuss all the possibilites here. Therefore to give you better advices it would be very helpful to let us know what problem you are trying to solve ;-)

Marco

[Campbell Ritchie]

You would do better to find a book or the Java® Tutorials.

This forum is for asking questions about the Ranch itself, so I shall move this discussion somewhere more appropriate.

[Mohit Chauhan]

Hi Marco,

Thanks for your quick and valuable response .

Actually i am using Future , Callable in Cache implementation.
I am using map as a cache which can be searched instead of going to particular implementations.

Code is as below :

	
public interface Computable<A, V> {
V compute(A arg) throws InterruptedException;
}

public class ExpensiveFunction
implements Computable<String, BigInteger> {
public BigInteger compute(String arg) {
// after deep thought...
return new BigInteger(arg);
}
}

public class Memoizer3<A, V> implements Computable<A, V> {
private final Map<A, Future<V>> cache= new ConcurrentHashMap<A, Future<V>>();
private final Computable<A, V> c;
public Memoizer3(Computable<A, V> c) { this.c = c; }

public V compute(final A arg) throws InterruptedException {
Future<V> f = cache.get(arg);
if (f == null) {
Callable<V> eval = new Callable<V>() {
public V call() throws InterruptedException {
return c.compute(arg);
}
};
FutureTask<V> ft = new FutureTask<V>(eval);
f = ft;
cache.put(arg, ft);
ft.run(); // call to c.compute happens here
}
try {
return f.get();
} catch (ExecutionException e) {
throw launderThrowable(e.getCause()); 
}
}
}

In Memoizer3 particularly in compute(A) . Here if value is not in cache then cretea it and put it in cache otherwise if value was already there in cache then directly take that value.

There can be a case where first thread passes the check that value is not in cache and tries to get it from actual implementation , and in the mean time i have some other thread which also try to access the same code .Now there can be possibility that second thread which is querying for the same A object but since we didn;t reached a point where we add required value in cache map during first thread execution
This will lead to case where value is not present in map but it is in the process of being added .So this will actually lead to a case where values will be taken from direct implementation instead of cache, which is not correct .

ie :
t1 => compute(A1);
t2 => compute(A1);

So in this context i want to know will future.get save us from it ?

[Above complete code can be found at Java Concurrency in Practice Pgno-74 ebook]

[Marco Ehrentreich]

Hi Mohit,

I think using Futures this way just complicates your implementation and doesn't have any advantages ;-)

If you really want to implement something like a cache yourself than it could be enough to use an ordinary ConcurrentHashMap for this purpose. With Java 8 it has even more nice features. I guess you'll find enough examples on Google.

Anyway, you probably should consider to use an existing caching framework or something like that for production use!


Marco

[Henry Wong]

On a previous train of thought...

Marco Ehrentreich wrote:
your understanding of Future.get() is correct. Calling get() will block your current thread until the computation is finished (additionally you can specify a timeout).

Additionally, if you don't want to call get() when the result isn't available yet, you can also call the isDone() method to check first. This way, your thread won't block on calculations still in progress, and can move on to doing something else.

Henry

[Mohit Chauhan]

Hi Henry,

It means if i have three threads being executed through Callable/Future service and if first thread is taking much longer , keeping a check early on future with isDone() makes my other threads to work without any blocking or waiting for first thread results.

However if i use the same implementation without isDone() , then my run will be stuck until first thread completes and gets result ?

[Henry Wong]

Mohit Chauhan wrote:
It means if i have three threads being executed through Callable/Future service and if first thread is taking much longer , keeping a check early on future with isDone() makes my other threads to work without any blocking or waiting for first thread results.

However if i use the same implementation without isDone() , then my run will be stuck until first thread completes and gets result ?

I don't understand the concern here. You have a bunch of threads, and either ... they need each others result or they don't (or likely a combination of both). If they have stuff to do that don't require the other's result, then do those first. Why wait for data until you need it? And if they need the result of each other's thread, then they have no choice. Threads may have dependencies and that can lose parallelism -- this isn't any different.

Henry

[Mohit Chauhan]

Hi,

I am aware of Callable and Future working on the outer side . Can somebody please give an overview , which locking mechanisam it internally uses (is it synchronisation or some other ).

Also while going through internals of Executor service where we use Callable-Future combination.While submitting calllables we are internally using Reentrant Locks while creating those threads.
Are we using the some Locking technique ??



Thanks
Mohit Gupta