As far I know, thread pools (java.util.concurrent.Executor class) provide a queue of tasks for all threads in a pool. So I don't really know, which thread will execute my task. But I need to have queues of tasks assigned to every thread. How can I do it?
If you want only certain threads to execute certain tasks you a standard Threadpool will not fit.
But you can use multiple Threadpools with only one thread in each to solve your problem.
You should write your program so you don't need to know what thread executes a task. They are just anonymous worker threads.
However, if you really want to know anyway you can create a single threaded ExecutorService for each thread you want and then you will know which thread will execute a task.
Related
I am creating thread pools like this:
ExecutorService workers = Executors.newCachedThreadPool();
Invoking each pool tasks like this:
workers.invokeAll(tasks);
And after completion shutting those down like this:
workers.shutdown();
I have about 4 thread pools that do different procedures and those thread pools are being created from a servlet class.
What I want to do is shutdown all threads in those thread pools.
What is the cleanest way to achieve this?
Thanks
If all your worker tasks handle interrupts properly you could try to invoke:
workers.shutdownNow()
That call with typically send interrupts too all worker threads. However, proper interrupt handling is a bit implicit and the method documentation says that only a best effort attempt to stop the tasks is made. Hence, some JVM implementations might make a worse attempt than sending interrupts, why you might not want to trust this call.
You might want to look into other answers how to gracefully ensure proper shutdown of threads and implement such a solution for all your worker tasks, to guarantee proper shutdown. For example, in this answer, Jack explains the typical solution to have a volatile field that you can check in your workers. This field can be set from where you want to stop your tasks.
Suppose there are three threads created using executor service and now I want that t2 would start running after t1 and t3 would start running after t2. how to achieve this kind of scenario in case of thread pool?
If it would have any normal thread creating using thread.start(). I could have waited using join() method. But how to handle above scenario?
Thread t1,t2 and t3 can implement callable interface and from the call method you can return some value.
Based on the return value, after t1 returns, you can initiate t2 and similarly for t3.
"Callable" is the answer for it
You are confusing the notion of threads and what is executed on a thread. It doesn't matter when a thread "starts" in a thread pool but when execution of your processing begins or continues. So the better statement is that you have 3 Callables or Runnables and you need one of the to wait for the other two before continuing. This is done using a CountDownLatch. Create a shared latch with a count of 2. 2 of the Callables will call countDown() on the latch, the one that should wait will call await() (possibly with a timeout).
Jobs submitted to an ExecutorService must be mutually independent. If you try to establish dependencies by waiting on Semaphores, CountDownLatches or similar, you run the risk of blocking the whole Service, when all available worker threads execute jobs that wait for a jobs that has been submitted, but is behind the current jobs in the queue. You want to make sure you have more workers than possible blocking jobs. In most cases, it is better to use more than one ExecutorService and submit each job of a dependent group to a different Service.
A few options:
If this is the only scenario you have to deal with (t1->t2->t3), don't use a thread pool. Run the three tasks sequentially.
Use some inter-thread notification mechanism (e.g. BlockingQueue, CountDownLatch). This requires your tasks to hold a shared reference to the synchronization instrument you choose.
Wrap any dependence sequence with a new runnable/callable to be submitted as a single task. This approach is simple, but won't deal correctly with non-linear dependency topologies.
Every task that depends on another task should submit the other task for execution, and wait for its completion. This is a generic approach for thread pools with dependencies, but it requires a careful tuning to avoid possible deadlocks (running tasks may wait for tasks which don't have an available thread to run on. See my response here for a simple solution).
I'm trying to understand the Reactor pattern (concurrent), but in many examples they are talking about 'worker threads'. What are worker threads? In what way do they differ from 'normal' threads? And what is their role in the reactor pattern?
The Reactor pattern is used with worker threads to overcome a common scenario in applications: You need to do a lot of work eventually but you don't know which work and when and creating threads is an expensive operation.
The idea is that you create a lot of threads which don't do anything at first. Instead, they "wait for work". When work arrives (in the form of code), some kind of executor service (the reactor) identifies idle threads from the pool and assigns them work to do.
That way, you can pay the price to create all the threads once (and not every time some work has to be done). At the same time, your threads are generic; they will do whatever work is assigned to them instead of being specialized to do something specific.
For an implementation, look at thread pools.
What are worker threads, and what is their role in the reactor pattern?
I assume you are talking about something like this documentation on thread-pools:
Most of the executor implementations in java.util.concurrent use thread pools, which consist of worker threads. This kind of thread exists separately from the Runnable and Callable tasks it executes and is often used to execute multiple tasks.
Worker threads are normal threads but they exist separate from the Runnable or Callable classes that they work on. If you extend Thread or you construct a Thread with a Runnable argument, the task is tied to the Thread object directly.
When you create a thread-pool using Executors.newFixedThreadPool(10); (or other similar methods), you create a pool of 10 threads that can run any number of different Runnable or Callable classes that are submitted to the pool. Underneath the covers they are still a Thread just more flexible because of the way they are wrapped.
In terms of the reactor pattern, different types of events are run by the handler threads which is similar. A thread is not tied to a single event class but will run any number of different events as they occur.
Here is what I want to do:
There are many threads start at any time, and each thread will run about 5s. When one thread is running, others must wait. And when the running thread ends, the newest thread start to run and other waiting threads just stop.
Of course, there will be situations: when one thread start, there's no other thread.
I tried to use FutureTask, but failed. It seems too complex for me.
Can anyone give me some idea?
you might want to take a look at single-threaded executor, which will take your tasks from task queue and invoke them sequentially.
it is more convenient to use this class if you will decide later to add some concurrency
Trying to wrap my head around Java concurrency and am having a tough time understanding the relationship between thread pools, threads, and the runnable "tasks" they are executing.
If I create a thread pool with, say, 10 threads, then do I have to pass the same task to each thread in the pool, or are the pooled threads literally just task-agnostic "worker drones" available to execute any task?
Either way, how does an Executor/ExecutorService assign the right task to the right thread?
Typically, thread pools are implemented with one producer-consumer queue that all of the pool threads wait on for tasks. The Executor does not have to assign tasks, all it has to do is push them onto the queue. Some thread, a 'task-agnostic worker drone', will pop the task, execute its 'run()' method and, when complete, loop round to wait on the queue again for more work.
If I create a thread pool with, say, 10 threads, then do I have to pass the same task to each thread in the pool, or are the pooled threads literally just task-agnostic "worker drones" available to execute any task?
More or less the latter. Any given task gets assigned to the next available thread.
Either way, how does an Executor/ExecutorService assign the right task to the right thread?
There is no such thing as the "right" thread. The task (i.e. the Runnable) needs to be designed so that it doesn't matter which thread runs it. This is not normally an issue ... assuming that your application properly synchronizes access / updates to data that is potentially used by more than one threads.