Method call to Future.get() blocks. Is that really desirable?
Solution 1
Future
offers you method isDone()
which is not blocking and returns true if computation has completed, false otherwise.
Future.get()
is used to retrieve the result of computation.
You have a couple of options:
- call
isDone()
and if the result is ready ask for it by invokingget()
, notice how there is no blocking - block indefinitely with
get()
- block for specified timeout with
get(long timeout, TimeUnit unit)
The whole Future API
thing is there to have easy way obtaining values from threads executing parallel tasks. This can be done synchronously or asynchronously if you prefer, as described in bullets above.
UPDATE WITH CACHE EXAMPLE
Here is a cache implementation from Java Concurrency In Practice, an excellent use case for Future
.
- If the computation is already running, caller interested in result of computation will wait for computation to finish
- If the result is ready in the cache, caller will collect it
- if the result is not ready and computation has not started yet, caller will start computation and wrap result in
Future
for other callers.
This is all easily achieved with Future
API.
package net.jcip.examples;
import java.util.concurrent.*;
/**
* Memoizer
* <p/>
* Final implementation of Memoizer
*
* @author Brian Goetz and Tim Peierls
*/
public class Memoizer <A, V> implements Computable<A, V> {
private final ConcurrentMap<A, Future<V>> cache
= new ConcurrentHashMap<A, Future<V>>();
private final Computable<A, V> c;
public Memoizer(Computable<A, V> c) {
this.c = c;
}
public V compute(final A arg) throws InterruptedException {
while (true) {
Future<V> f = cache.get(arg);
// computation not started
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 = cache.putIfAbsent(arg, ft);
// start computation if it's not started in the meantime
if (f == null) {
f = ft;
ft.run();
}
}
// get result if ready, otherwise block and wait
try {
return f.get();
} catch (CancellationException e) {
cache.remove(arg, f);
} catch (ExecutionException e) {
throw LaunderThrowable.launderThrowable(e.getCause());
}
}
}
}
Solution 2
Below is the snippet of the pseudo code. My question is- Does the below code not defeat the very notion of parallel asynchronous processing?
It all depends on your use case:
-
If you really want to block till you get the result, use blocking
get()
-
If you can wait for a specific period to know the status instead of infinite blocking duration, use
get()
with time-out -
If you can continue without analysing the result immediately and inspect the result at future time, use CompletableFuture (java 8)
A Future that may be explicitly completed (setting its value and status), and may be used as a CompletionStage, supporting dependent functions and actions that trigger upon its completion.
-
You can implement callback mechanism from your Runnable/Callable. Have a look at below SE question:
Java executors: how to be notified, without blocking, when a task completes?
Solution 3
I would like to give my share on this one, more on theoretical point of view as there are some technical answers already. I would like to base my answer on the comment:
Let me give you my example. The tasks I submit to the service end up raising HTTP requests, The result of the HTTP request can take a lot of time. But I do need the result of each HTTP request. The tasks are submitted in a loop. If I wait for each task to return (get), then I am loosing parallelism here, ain't I?
which agrees with what is said in the question.
Say you have three kids, and you want to make a cake, for your birthday. Since you want to make the greatest of cakes you need a lot of different stuff to prepare it. So what you do is split the ingredients on three different lists, because where you live there exist just 3 supermarkets that sell different products, and assign each of your kids a single task, simultaneously
.
Now, before you can start preparing the cake (let's assume again, that you need all the ingredients beforehand) you will have to wait for the kid that have to do the longest route. Now, the fact that you need to wait for all the ingredients before starting to make the cake is your necessity, not a dependency among tasks. Your kids have been working on the tasks simoultaneously as long as they could (e.g: until the first kid completed the task). So, to conclude, here you have the paralelilsm.
The sequential example is described when you have 1 kid and you assign all three tasks to him/her.
Solution 4
In the example you have given you might as well run everything in your main()
method and go your merry way.
But let us assume you have three steps of computation that you are currently running sequentially. Just for understanding let us assume that step1 takes t1 seconds, step2 takes t2 seconds, and step3 takes t3 seconds to complete. So total computation time is t1+t2+t3
. Also, let us assume that t2>t1>=t3
.
Now let us consider a scenario when we executed these three steps in parallel using Future
to hold each computational results. You can check if each task is done using non-blocking isDone()
call on corresponding futures. Now what happens? theoretically your execution is as fast as how t2
completes right? So we did gain some benefits from parallelism.
Also, in Java8 , there is CompletableFuture
that supports functional style call backs.
Solution 5
If you don't care about the results, then spawn a new thread and from that thread use ExectorService
API for task submission. In that way, your parent thread i.e main
thread will not be blocking in any way, it would simply spawn a new thread and then will start further execution, while the new thread will submit your tasks.
For creating new thread - either do it yourself by having a ThreadFactory
for your async thread creation or use some implementation of java.util.concurrent.Executor
.
If this is in a JEE application and you are using Spring framework then you can easily create a new asynchronous thread using @async
annotation.
Hope this helps!
Related videos on Youtube
TheMonkWhoSoldHisCode
Updated on August 03, 2020Comments
-
TheMonkWhoSoldHisCode almost 4 years
Please read the question carefully before marking this as duplicate.
Below is the snippet of the pseudo code. My question is- Does the below code not defeat the very notion of parallel asynchronous processing?
The reason I ask this is because in the below code the main thread would submit a task to be executed in a different thread. After submitting the task in the queue, it blocks on Future.get() method for the task to return the value. I would rather have the task executed in the main thread rather than submitting to a different thread and waiting for the results. What is that I gained by executing the task in a new thread?
I am aware that you could wait for a limited time etc, but then what if I really care about the result? The problem gets worse if there are multiple tasks to be executed. It seems to me that we are just doing the work synchronously. I am aware of the Guava library which provides a non blocking listener interface. But I am interested to know if my understanding is correct for the Future.get() API. If it is correct, why is the Future.get() designed to block thereby defeating the whole process of parallel processing?
Note - For the record, I use JAVA 6
public static void main(String[] args){ private ExectorService executorService = ... Future future = executorService.submit(new Callable(){ public Object call() throws Exception { System.out.println("Asynchronous Callable"); return "Callable Result"; } }); System.out.println("future.get() = " + future.get()); }
-
Yosef Weiner almost 9 yearsThe idea is that you would submit multiple tasks and then wait. You are right that if you wait for the result in between submitting each task, then they will be processed in serial and you won't gain anything.
-
TheMonkWhoSoldHisCode almost 9 years@SkinnyJ If multiple tasks are submitted, how do you know the result returned is for which task? And how do i wait for multiple tasks?
-
John almost 9 years@VishalP You will then have list of Futures which you could check with isDone() or fetch result with get()
-
Yosef Weiner almost 9 yearsThe simplest is to use invokeAll. Otherwise, you can keep track of each future as you submit its Callable, and get the results one after the other. Either way, the processing is happening in parallel.
-
overexchange over 6 years@TheMonk What made you you accept the answer? Is it because observer pattern is the solution to wait asynchronously?
-
Enrique almost 6 yearsThe important thing is that "get" is not starting the execution, "submit" is, get is only "waiting" the result. So we could start multiple tasks (multiple executors) and then use get on every one. In that way all the executors will run in parallel. If you can continue without the result instead of get you could use the Observer pattern
-
Bishnu over 3 yearsI was wondering how get(..) would be working, but looking at the source code it just yields the processor for a preemption but literally doesn't release thread in the worst case. Anyone has worked with C++ (or other langs) which supports non-blocking wait with timeout feature
-
-
TheMonkWhoSoldHisCode almost 9 yearsBut then you still wait in a loop checking isDone(), isn't this blocking as well?
-
John almost 9 yearsThis entirely depends on your design. You don't have to. For example you could have one thread dispatching events as they come into system, and also periodically check for result. In this scenario checking for results if they are not ready would not block and thread could continue with dispatching events. There are many patterns which could be used here to avoid blocking. Check Observer Pattern which could be used to notify of result, also Active Object Pattern and Half Sync - Half Async, Publish Subscribe. Try to read up a bit on these patterns to get idea how to use asynchronous programming.
-
TheMonkWhoSoldHisCode almost 9 yearsLet me give you my example. The tasks I submit to the service end up raising HTTP requests, The result of the HTTP request can take a lot of time. But I do need the result of each HTTP request. The tasks are submitted in a loop. If I wait for each task to return (get), then I am loosing parallelism here, ain't I ?
-
TheMonkWhoSoldHisCode almost 9 yearsYou are right. But I still wonder if this is made unnecessarily complex. An out of the box listener solution would have been very handy.
-
John almost 9 yearsThis Listener would most likely be Observer in a simple Observer Pattern. You can probably figure that one in 20 minutes on your own:) This might be helpful : tutorialspoint.com/design_pattern/observer_pattern.htm
-
TheMonkWhoSoldHisCode almost 9 yearssure thnx a ton for the valuable info. Very much appreciated :)
-
ring bearer almost 9 yearsNo, invoke get only when your isDone() returns
true
. That is better than executing all the calls sequentially. So essentially, your execution will be only as fast as the slowest performing web service (including network etc) -
hagrawal almost 9 years@VishalP Have got some answer?
-
Dheeru Mundluru almost 8 yearsAssuming, you want timeout involved, then I think as @SkinnyJ pointed out you can simply use invokeAll as it does the same thing as isDone & get combo. You can then use Future.isCancelled before using get.
-
TheMonkWhoSoldHisCode over 7 yearsthnx @ravnidra. I wasn't using 1.8 then, so CompletableFuture was out of question. But the other inputs are pretty relevant.
-
pramodc84 almost 6 yearsbaeldung.com/java-future - this is simple and yet great example.