So I'm still a bit new to multithreading and came across these two classes. What I understood is that an ExecutorService can be a thread pool and via the awaitTermination method the thread in which it is called comes to a halt until the threads in the thread pool have finished running.
Then there is the CountDownLatch you can give to your Runnables. These can then in turn call the countDown() method. If you then use the await() method in your main thread, this thread will come to a halt until the countdown has reached zero.
I don't seem to spot the difference in result between the two ways? Why would I ever use a CountdownLatch?
There are lots of different things where you might want to wait for lots of things to be processed that don't involve shutting down your thread pool.
For example you might have 5 servers that you are monitoring, with a thread to monitor each one. A Countdown Latch is used to fire off another thread once all the first 5 have connected.
It can also be used in many other situations, for example if you have some initialization to happen then all the threads may wait on the countdown latch until all the initialization has finished and the latch is counted down to zero.
Related
After seaching a lot and not finding a concrete answer
If I have two threads started:
Thread t1 = new Thread();
Thread t2 = new Thread();
t1.start();
t2.start();
After starting the threads I need the main thread to wait for these two thread to finish before printing the final result
How can I make the main thread wait for both t1 and t2?
A plain wait() would be enough?
Add
t1.join();
t2.join();
in your thread which should wait till t1 and t2 will finish their tasks (in your case call it from your main thread).
The answer depends...
You could
Use a CountDownLatch which is probably the simplest solution.
This way you would simply wait on the latch until it has been signaled the prescribed number of times (by each Thread terminating). This scales quite nicely as you increase the number of threads...
You could
Use join, but it would become tedious as you add more threads
You could
Add each Thread to a List, loop through the list, removing those threads that are no longer alive and keep looping until the List is empty, but that's a rather heavy handed approach.
You could
Combine the above solution with some kind of monitor lock which the loop would wait on and each Thread would notify when they complete, but it's not much cleaner and you could still end up waiting for non-existent threads...
You could
Use an ExecutorService and either use it's invokeAll and/or shutdown methods. See Executors for more details. This also scales quite nicely and even has the added benefit of allowing you to use a Thread pool to better manage the system resourcs
Check out the Thread#join method.
Also, you might find using an ExecutorService (and friends) helpful. Its essentially thread pool/management and provides a lot of conveniences and IMO a cleaner API than threads. Barrier to entry is low...
You want Thread#join(). wait() is for signalling, join() is to wait for the thread to finish.
When I was going through Javadoc for CountDownLatch, I came across a line in the documentation for await method.
If the current count is greater than zero then the current thread
becomes disabled for thread scheduling purposes and lies dormant
What is meant by current thread becomes disabled for thread scheduling purposes here?
On a given system, only a fixed number of threads can actually execute at the same time (you're limited by the number of cores in the machine.) When there are more threads to run than there are cores, the thread scheduler will cycle through the threads in some fashion, giving each a bit of time on the CPU.
However, in some cases it doesn't make sense to give a thread time on the CPU. For example, if a thread acquires a countdown latch whose total is greater than zero, then that thread is stuck waiting for other threads to also acquire the latch. It therefore doesn't make any sense to let that thread have any CPU time, since the thread is just sitting and waiting for other threads. Therefore, typically, the scheduler would not even attempt to give the thread any CPU time, preferring instead to schedule other threads that can still make progress. Once enough threads do acquire the countdown latch, all threads that were blocked this way are then put back into the scheduler for further consideration.
In other words, the thread stops running and the scheduler will intelligently not waste time trying to run it until the latch is ready.
Hope this helps!
It just means that the code in that thread will not go any further until latch.countDown() is called on the same latch from other threads thereby making the latch count 0.
A thread runs when it is in runnable state and the scheduler schedules it. When a threads is disabled for scheduling, it will not get its share of cpu cycles, so it wont run which means its program counter will not increase. Its stack will freeze where it was till it gets the cpu again.
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've got an application with a possible number of threads. basicly the threads should work this:
Main Thread
CalculationThread
CalculationThread
CalculationThread
Adding / Executing those threads to a FixedThreadPool isn't the problem. The Thread itself calls a certain function in the Mainthread to submit the results. After this step, the thread should sleep until it will be called again for the next calucation.
The Mainthread holds a reference to a CalculationThread to submit updates to the thread and readd it to the pool to start the next calculation.
My Problem: How can I enforce a timeout for a certain thread? The enforcement of this timeout must also work, if a endless loop occurs
You cannot enforce the timeout without cooperation from the thread, at least not in a sane way. You should code your calculation tasks so that they comply with the Java interruption mechanism. Basically, that means occasionally checking the Thread.interrupted return value and aborting on true.
The only other option is the ham-handed – and deprecated – Thread.stop, which can wreak general chaos, especially when done on a pool-managed thread.
I have some developpements to do and I try to see if there is a desing pattern to use.
The problem is simple:
I have a main thread that launches many treads. The main thread must wait for each thread to finish and then doing something else.
The existing code it's a bit ugly. I have a while loop that check a thread group to see if is something running:
//launch threads
.....
//wait for threads to finish
while (ThreadRepository.getInstance().isActiveThreadGroup(myGroupId)) {
Thread.sleep(5000);
}
//doing something else
So, as you see, the while loop keeps running until no threads running.
I was thinking at the pattern producer-consumer and I would like to do something like that:
Using some BlockingQueue for instance, and each thread put (or take) something in it.
Instead of having the while and sleep I would like to have something like
myQueue.take() but something to wait for the queue to be empty.
When empty, it means no threads running.
I try to search on the Internet but I did not found something that matches my problem.
Does anyone know the most efficient to solve my problem ?
There are two easy ways to have one thread wait for N threads to finish:
Make the main thread call join() on all the other threads. join() returns when a thread finishes, or has already finished
Create a CountDownLatch initialized to N, pass this latch to all the threads, make each thread call countDown() on the latch when it has finished, and make the main thread call await() on the latch. This second technique is a bit harder than the first one, but is also more flexible and reusable, and allows being awaken after some delay, even if the N threads have not finished yet.
You can use BlockingQueue as follows:
each child thread puts a message in the queue when finished
the main thread takes messages from the queue and counts them. When the number of messages equals the number of threads, all threads has finished.