Develop Reference

Killing a thread invoked asynchronously using executor service

I am trying to implement timeout for a thread which is invoked asynchronously by executor.
Process flow is like below:
Thread-1: Initiates a task to run on thread-2 using below code and returns immediately without waiting for Future object result
Thread-2: Long process and wil update some store some result in cache at end
Now, the requirement is to kill Thread-2 after some timeout value without blocking Thread-1
code snippet:
ExecutorService executor = Executors.newFixedThreadPool(1);
Future<Task> future = executor.submit(new Callable<Task>() {
public Task call() throws Exception {
try{
return new Task();
}catch (Exception e) {
//print stack
}
}
});
Any insight/suggestions to implement this?

See the following answer: https://stackoverflow.com/a/2733370/1299078
But depending on what Thread-2 does, you could let the thread end regularly, i.e. define a timeout on a http-request or a DB statement or if you have a loop, define an exit condition. this way you may end up with a more proper solution and you are able to properly release resources.

You can't do it using Java's ExecutorService because it doesn't expose any method to timeout and kill/complete/finish the newly spawned thread.
However, if you must do it then you can do it by directly using Thread class, below is high level approach:
From your main thread t1, spawn your worker thread t2 which is supposed to do your long work.
In your t1, you will have hold of the t2's ORV, pass it a new thread t3 along with time after which you want t2 to finish.
In t3 (you can also do this in t1 if you wish, but since you do not wish to block t1 so you need to have another thread to do this job), once that time has elapsed call t2.interrupt(), this will basically interrupt the t2 thread.
Now in t2, you will have to periodically keep on checking whether the thread is interrupted or not (using if (Thread.interrupted()) {) and if it is interrupted then you can do whatever you want to do like - simply return therefore completing/killing/finishing the thread.

The basic ExecutorService does not provide a timeout functionality.
You could implement the timeout yourself like described by #hagrawal or you can use guava which has a very nice implementation for what you're asking for here

What synchronization primitive should I use to implement a event driver framework in Java?

I have a looper thread to execute tasks. Other threads can submit tasks to this looper thread. Some tasks are immediate tasks, others are future tasks, which are to be executed after T seconds after submission. I use PriorityBlockingQueue to store tasks, where time is used as the priority, so that the first task of the queue is the most imminent task to be executed.
The looper's main loop is as fellows:
PriorityBlockingQueue<Event> taskQueue = ...
while (true) {
if (taskQueue.isEmpty())
<something>.wait(); // wait indefinitely
else
<something>.wait(taskQueue.peek().time - NOW()); // wait for the first task
Task task = taskQueue.poll(0); // take the first task without waiting
if (task != null && task.time <= NOW())
task.execute();
else if (task != null)
taskQueue.offer(task); // not yet runnable, put it back
}
The looper provides allows other threads (or itself) to submit tasks:
public void submitTask (Task task) { // time information is contained in the task.
taskQueue.offer(task);
<something>.signal(); // informs the loop thread that new task is avaliable.
}
Here, I have only one thread calling wait() and multiple threads calling signal(). My question is that what synchronization primitive should I use in the place of <something>. There are so many primitives in the java.util.concurrent and java.util.concurrent.lock package. And there are also the synchronized keyword and Object.wait()/notify(). Which one fits best here?

You don't need to do any of this.
The whole point of the BlockingQueue is that it already manages thread synchronization for you. You do not need to inform other threads that something new is available now.
Just use
taskQueue.take(); // blocks until something is there
or
taskQueue.poll(1, SECONDS); // wait for a while then give up
For your "future tasks" that should not be processed immediately, I would not add them to this queue at all. You can use a ScheduledExecutorService to add them to the task queue once it is time (in effect, a second queue).
Come to think of it, you can do away with the BlockingQueue altogether and just use the ScheduledExecutorService (backed by a single thread, your "looper") for all your tasks.

j.u.c. package contains DelayedQueue which can satisfy you problem.
Every queued object should implement Delayed interface with getDelay(..) method.

What is the difference between join and CountDownLatch?

When waiting for other threads to finish, we can use either join or CountdownLatch. What are the pros and cons of using either of those two mechanisms?

You can only use Thread.join if you're handling the threads yourself. Most people choose not to deal with the minutia of thread handling directly, and instead use an ExecutorService to handle it for them. ExecutorServices do not directly reveal how they are executing tasks, so you would have to use a CountDownLatch: (Assuming you don't want to just shutdown the whole service, that is.)
ExecutorService service = Executors.newFixedThreadPool(5);
final CountDownLatch latch = new CountDownLatch(5);
for(int x = 0; x < 5; x++) {
service.submit(new Runnable() {
public void run() {
// do something
latch.countDown();
}
});
}
latch.await();

Another difference is after join(), thread can be unblocked only when joined thread has finished its execution while in CountDownLatch a thread can decrease the count anytime either on completion of thread or in between based on any condition.
This way we can get better control over unblocking of the thread instead of solely depending on the completion of joined thread.

join() is waiting for another thread to finish while CountDownLatch is designed for another purpose. If using CountDownLatch, You don't have to have reference of threads for which you are waiting as we have to do using join(). Let's assume you want to start a game when at least 2 players should be available. You can use countdownlatch in this case. But you can't achieve this using join easily because you don't have another thread(player in this case) on which you can write join().

A CountdownLatch is task-oriented - it's thread-agnostic. A whole pile of unrelated sets of tasks can be submitted to a threadPool and a CountdownLatch will ensure that each set notifies the originator of completion. Join() is an annoying abberation that links tasks to threads and, simply put, should never have entered the language in the first place. Sadly, a large, steaming pile of thread-tutorials mention Join() on the first page, thereby introducing threads to newbies as a deadlock-generator and generating thread-funk :(

CountdownLatchallows you to change the implementation of Item to maybe submit to an Executor service instead of using Threads directly.
The CountDownLatch class allows us to coordinate the starting and stopping of threads. Typical uses are as follows:
We can make several threads start at the same time;
We can wait for
several threads to finish (whereas, for example, the Thread.join()
method only lets you wait for a single thread).
You can have a look at this -> http://javahowto.blogspot.com/2011/08/when-to-join-threads-with.html
And this ->
A CountDownLatch's latch.await() method vs Thread.join()

Java: ExecutorService with Callables: Reuse the same Pool in a loop? Shutdown necessary?

I got a loop {Loop-1}, where I start Threads. The class which contains the {Loop-1} implements Daemon and Runnable.
In the {Loop-1} the thread, which is started, calls a method coordinate() of a class Coordinate.java where I use the ExecutorService.
When the object of Coordinate.java is created (this happens once BEFORE {Loop-1}), I instantiate a ExecutorService
pool = Executors.newFixedThreadPool(2);
In coordinate() I create two Objects of a class which implements Callable and I start them then and store the result in a List of Future results.
callableResults = pool.invokeAll(threads);
After, I try to get the results in a loop with result = future.get();
Then, I return to {Loop-1} and the whole process starts again (call coordinate(), invokeAll(), future.get()
Now Ive got the following question:
1. Do I need to shutdown the pool of ExecutorService after I got the results in coordinate()?
2. Do I need to recreate the pool everytime my {Loop-1} calls coordinate()?
Thanks for answers! :-)

No you do not. The threads in the fixed thread pool can be used until you call shutdown on it. So, you can simply resubmit new tasks to be executed and fetch their results, exactly as you did in the first go-round.

You need to shutdown the executorService once you're done processing all your tasks.
The submission of tasks can be in multiple cycles.
Once you call executorService.shutDown(), you can wait until all tasks are completed after calling shutDown() using executorService.awaitTermination(10, TimeUnit.SECONDS).
Alternatively, you can do: while (!executorService.isTerminated()) { }

Java producer/consumer, detecting end of processing

I'm preparing an application where a single producer generates several million tasks, which will then be processed by a configurable number of consumers. Communication from producer to consumer is (probably) going to be queue-based.
From the thread that runs the producer/generates the tasks, what method can I use to wait for completion of all tasks? I'd rather not resume to any periodic polling to see if my tasks queue is empty. In any case, the task queue being empty isn't actually a guarantee that the last tasks have completed. Those tasks can be relatively long-running, so it's quite possible that the queue is empty while the consumer threads are still happily processing.
Rgds, Maarten

You might want to have a look at the java.util.concurrent package.
ExecutorService
Executors
Future
The executor framework already provides means to execute tasks via threadpool. The Future abstraction allows to wait for the completition of tasks.
Putting both together allows you coordinate the executions easily, decoupling tasks, activities (threads) and results.
Example:
ExecutorService executorService = Executors.newFixedThreadPool(16);
List<Callable<Void>> tasks = null;
//TODO: fill tasks;
//dispatch
List<Future<Void>> results = executorService.invokeAll(tasks);
//Wait until all tasks have completed
for(Future<Void> result: results){
result.get();
}
Edit: Alternative Version using CountDownLatch
ExecutorService executorService = Executors.newFixedThreadPool(16);
final CountDownLatch latch;
List<Callable<Void>> tasks = null;
//TODO: fill tasks;
latch = new CountDownLatch(tasks.size());
//dispatch
executorService.invokeAll(tasks);
//Wait until all tasks have completed
latch.await();
And inside your tasks:
Callable<Void> task = new Callable<Void>()
{
#Override
public Void call() throws Exception
{
// TODO: do your stuff
latch.countDown(); //<---- important part
return null;
}
};

You want to know where every tasks completes. I would have another queue of completed task reports. (One object/message per task) When this count reaches the number of tasks you created, they have all completed. This task report can also have any errors and timing information for the task.

You could have each consumer check to see if the queue is empty when they dequeue, and, if it is, pulse a condvar (or a Monitor, since I believe that's what Java has) on which the main thread is waiting.
Having the threads check a global boolean variable (marked as volatile) is a way to let the threads know that they should stop.

You can use join() method for each thread ..so that till all the threads are done your main thread will not end! And by this way you can actually find out whether all the threads are done or not!