I was developing a JavaFX app and I was supplying the JavaFX tasks in an ExecutorService submit method. Also I was trying to get the return value of the Task in the return value of the submit in a Future object. Then I discovered that ExecutorService only returns value when you submit a Callable object, and JavaFX Tasks are runnables despite having a call method. so is there any workaround for this problem?
I tried and solved my problem this way but I'm open to suggestions when I don't want to write my own class.
My main method:
public static void main(String[] args) throws InterruptedException, ExecutionException {
ExecutorService executorService = Executors.newSingleThreadExecutor();
Semaphore semaphore = new Semaphore(1);
List<Integer> list = IntStream.range(0,100).boxed().collect(Collectors.toList());
Iterator<Integer> iterator = list.iterator();
while (iterator.hasNext()){
List<Integer> sendingList = new ArrayList<>();
for (int i = 0; i < 10; i++) {
sendingList.add(iterator.next());
}
System.out.println("SUBMITTING");
Future<Integer> future = executorService.submit((Callable<Integer>) new TestCallable(sendingList,semaphore));
System.out.println(future.get());
semaphore.acquire();
}
executorService.shutdown();
System.out.println("COMPLETED");
}
My TestCallable class:
class TestCallable extends Task<Integer> implements Callable<Integer> {
private Random random = new Random();
private List<Integer> list;
private Semaphore semaphore;
TestCallable(List<Integer> list, Semaphore semaphore) {
this.list = list;
this.semaphore = semaphore;
}
#Override
public Integer call(){
System.out.println("SENDING");
System.out.println(list);
try {
Thread.sleep(1000+random.nextInt(500));
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("RECEIVED");
semaphore.release();
return list.size();
}
}
Task extends java.util.concurrent.FutureTask which in turn implements the Future interface. This means you can use a Task just like a Future.
Executor executor = ...;
Task<?> task = ...;
executor.execute(task);
task.get(); // Future method
This will cause the thread calling get() to wait until completion. However, a Task's purpose is to communicate the progress of a background process with the JavaFX Application Thread. It's close relationship to the GUI means you will most likely be launching a Task from the FX thread. This will lead to get() being called on the FX thread which is not what you want as it will freeze the GUI until get() returns; you might as well have just called Task.run directly.
Instead, you should be using the asynchronous functionality provided by Task. If you want to retrieve the value when the Task completes successfully you can use the onSucceeded property or listen to the value/state property. There's also ways to listen for failure/cancellation.
Executor executor = ...;
Task<?> task = ...;
task.setOnSucceeded(event -> handleResult(task.getValue()));
task.setOnFailed(event -> handleException(task.getException()));
executor.execute(task);
If you don't need the functionality provided by Task then it would probably be best to simply use Runnable or Callable directly.
It's not very clear what you want to do here.
Firstly, your Semaphore does nothing because you used Executors.newSingleThreadExecutor(), which already guarantees that only one task can run at any point in time.
Secondly, like what #Slaw mentioned, you are potentially blocking on JavaFX Application thread, depending on your actual implementation (your example isn't really a JavaFX application).
Next, ExecutorService has 2 main overloads for submit().
The first overload takes in a Callable. This overload allows you to retrieve the value returned by the Callable (by calling get() on the returned Future), because Callable refers to something that is can be called - it can return value.
The second overload takes in a Runnable. Since Task implements Future RunnableFuture interface, and Future RunnableFuture interface extends Runnable interface, passing in a Task would be equivalent to calling this overload. This overload does not expect a result to be returned, because Runnable is something that you run without a result. Calling get() on the Future returned by this overload will block until the task finishes, and null will be returned. If you need to retrieve the value returned by the Task, you need to call get() of the Task, not the Future returned by ExecutorService.submit().
Edit based on OP's comments
Firstly, since the calling method is already running in a background thread, and all tasks are expected to run sequentially (instead of parallelly), then you should just run them without all these additional ExecutorService and Task, unless there is another reason why this has to be done.
Secondly, a List object is nothing but an object doing referencing. What could have really affected performance is that you are copying the reference of the elements to the new list. You could have used List.subList()if the indices are known, as the returned list would use the same backing array as the original list, so there isn't an additional O(n) operation for copying.
Related
I have a collection (concurrentHashMap) and a method which should work in a separate thread and return numOfApples:
public int getApples(String treeNum) {
int numOfApples = null;
Runnable task = () -> {concurrentHashMap.get(treeNum).getApples(); };
new Thread(task).start() ;
return numOfApples;
}
Is it possible to pass num of apples from lambda expression (concurrentHashMap.get(treeNum).getApples()) to the numOfApples variable?
The problem is not about returning the value from a lambda expression. It is about returning a result from an asynchronous task.
You won't be able to do that easily using a Runnable. You should use a Callable instead, quoting its Javadoc:
A task that returns a result and may throw an exception.
Also, you definitely should not be creating unmanaged raw threads like that: new Thread(task).start();. You should use an ExecutorService and submit the Callable to it.
Consider the following code:
public int getApples(String treeNum) {
Callable<Integer> task = () -> concurrentHashMap.get(treeNum).getApples();
Future<Integer> future = Executors.newCachedThreadPool().submit(task);
return future.get();
}
It creates a Callable<Integer> holding the task returning the number of apples. This task is submitted to an ExecutorService (I simply used a cached thread pool here, you might want another). The result is contained inside a Future<Integer> instance, whose get() method will block, wait for the result and then return it.
I have a question regarding using a single threaded executor. Since it reuses the same thread, does that means that If I modify an object state in one submit call, can I assume that another modification of that object state in subsequent calls of submit are thread safe? Let me give a toy example...
public class Main {
public static void main(String[] args) throws Exception {
final A a = new Main().new A();
ExecutorService executor = Executors.newSingleThreadExecutor();
Callable<Integer> callable = new Callable<Integer>() {
#Override
public Integer call() throws Exception {
return a.modifyState();
}
};
/* first call */
Future<Integer> result = executor.submit(callable);
result.get();
/* second call */
result = executor.submit(callable);
int fin = result.get();
System.out.println(fin);
executor.shutdown();
}
class A {
private int state;
public int modifyState() {
return ++state;
}
public int getState() {
return state;
}
}
}
So I am sharing object A. I submit a callable and modify it's state first ( see /* first call / ). I then do another submit call, modify again A state. (/ second call */).Now my big question
Is it safe to say that, since it's the same thread, the second submit call will see A.state as being 1? Or could it see it as being 0 in some cases too?
So basically I am asking if it's safe to modify variables that are not marked as volatile/accessed from synchronized blocks in subsequent submit calls of a single thread executor?, since it reuses the same thread
What exactly does thread reusing means regarding executors? Is it really the same thread at OS level in the case of an single thread executor?
It actually doesn't matter that it is single threaded. The javadoc of ExecutorService states:
Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken by that task, which in turn happen-before the result is retrieved via Future.get().
Executors.newSingleThreadExecutor() gives you thread safety by guaranteeing only one thread running at a time. It also gives you grantee about visibility which means any state change during one thread execution will be visible to next thread execution.
I have one "Runnable" threads which is initiating few "Callable" threads and I want to display results when all above threads has finished their jobs.
What is the best way to do it?
My code is as follows
Connector.java (Starting Runnable Thread)
public class Connector {
private static void anyFileConnector() {
// Starting searching Thread
ExecutorService executor = Executors.newFixedThreadPool(100);
executor.submit(traverse, executor);
//HERE I WANT MY ALL SEARCH RESULTS/OUTPUT : CURRENTLY IT IS STARTING OTHER THREADS AND NOT SHOWING ME ANY RESULTS BECAUSE NONE OF THEM WAS FINISHED.(IN CONSOLE, I WAS ABLE TO SEE RESULTS FROM ALL THE THREADS
setSearchResult(traverse.getResult());
executor.shutdown();
}
}
Traverse.java (Runnable Thread)
I am using ExecutorCompletionService to handle it...but it didn't create any difference.
:(
public class Traverse implements Runnable {
public void run() {
ExecutorService executor = Executors.newFixedThreadPool(100);
ExecutorCompletionService<List<ResultBean>> taskCompletionService =
new ExecutorCompletionService<List<ResultBean>>(executor);
try (DirectoryStream<Path> stream = Files
.newDirectoryStream(dir)) {
Search newSearch = new Search();
taskCompletionService.submit(newSearch);
}
list.addAll(taskCompletionService.take().get());
}
}
Search.java (Callable Thread)
public class Search implements Callable<List<ResultBean>> {
public List<ResultBean> call() {
synchronized (Search.class) {
// It will return results
return this.search();
}
}
}
Go for CyclicBarrier and you will be able to achieve this.
A cyclic barrier will perform a task as soon as all the threads are done with their work, this is where you can print the en result.
Check this lik for working of CyclicBarrier : http://javarevisited.blogspot.com/2012/07/cyclicbarrier-example-java-5-concurrency-tutorial.html
Easy - all the Callables will return Future objects which you can used to wait and get the result by calling Future.get() in a blocking wait way. So your problem is just a for loop waiting for each future on the callables blockingly.
After that, just aggregate the results to return to client.
The submit method of executor service can return a list of Future objects. What you can do for your case is call isDone() method of these Future objects in a while loop.
Whenever, any future task gets completed this method will return true. You can now call get() method on this to get the value returned by this task. In this way you could get hold of all the future task values without having to wait for any particular task to get complete (since your first future task could have the longest completion time)
I am running several tasks in a ThreadPoolExecutor. I initialise it as follows:
private VideoExportExecutor executor;
private BlockingQueue<Runnable> jobQueue;
public void initialiseVideoProcessor()
{
jobQueue = new LinkedBlockingQueue<Runnable>();
executor = new VideoExportExecutor(1, 1, Long.MAX_VALUE, TimeUnit.SECONDS, jobQueue);
}
I have made my own implementation of runnable (VideoExportThread) which contains a getProgress() method to keep track of the progress of submitted tasks. I submit instances of this as follows:
executor.submit(new VideoExportThread(gcmPath));
I am after a way to query the executor/blockingQueue for current/pending threads. I have tried to use jobQueue.toArray() and to override the executor method beforeExecute(Thread t, Runnable r) but in both cases the returned runnable is of type FutureTask which does not contain much data. Is there a way for me to use it to retrieve my original VideoExportThread instance in order to identify which ones are running and to query its progress?
Thanks
Why not simply keep a list of your Runnables?
List<Runnable> runnables = new ArrayList<> ();
VideoExportThread r = new VideoExportThread(gcmPath);
runnables.add(r);
executor.submit(r);
Also note that executor.submit(r); returns a Future - you can call its isDone() method to check if the submitted task is still running.
Side comment: there might be a good reason to manage the job queue manually, but if not, you use one of the factory methods to make your life easier. For example: ExecutorService executor = Executors.newCachedThreadPool();.
I have a Callable<String>. I want to run it periodically via ScheduledExecutorService.scheduleAtFixedRate(), and to get a list of all the Strings that were returned by the .call() invocations on my callable. As scheduleAtFixedRate does not take a Callable (only Runnables) I need to roll out a custom Runnable that wraps my Callable, something along these lines:
final Callable<String> myCallable = ....;
final ConcurrentLinkedQueue<String> results
= new ConcurrentLinkedQueue<String>();
Runnable r = new Runnable() {
#Override public void run() {
try {
results.add(myCallable.call());
} catch (Exception e) {
results.add(null); // Assuming I want to know that an invocation failed
}
}
};
ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
executor.scheduleAtFixedRate(r, 0, 1, TimeUnit.SECONDS);
Naturally, I'd like to avoid rolling out my own custom thingies (especially in multi-threaded code), so I wonder there is a JDK class that does this kind of aggregation?
What you are doing above is treating your Callable implementation as just another normal class. You are not submitting the callable to a ThreadPool executor. Calling Callable.call() doesn't utilize the ThreadPoolExecutor.
You need to submit your Task (Runnable/Callable/ForkJoinTask,etc..) to a ThreadPool to utilize the thread pooling.
You can use the Futures to collect the results once executed.
ForkJoinPool is one option you can try thats part of JDK 7. Fork the tasks and Join them using ForkJoinTask
Why not use Futures? They are exactly meant for knowing the state of Task and its result.
Did you look at this : Using Callable to Return Results From Runnables