Join v/s CountDownLatch/CyclicBarrier

[Vaibhav Gargs]

I have gone through the CountDownLatch & CyclicBarrier concepts.

I am just wondering if they are similar to join method. Please correct me if I am wrong.

If they are similar to join, why do we need CountDownLatch or CyclicBarrier? In which specific scenario, we should use all of these?

[Stephan van Hulst]

You should never use join() because you should not operate on threads directly. The Java designers recognized this, and added the high level concurrency library, which includes CountDownLatch and CyclicBarrier.

You use a CountDownLatch to block any number of threads until a certain number of tasks have been completed.

You use a CyclicBarrier to block a certain number of threads until that number of threads have reached the barrier.

[Vaibhav Gargs]

Stephan van Hulst wrote:You should never use join() because you should not operate on threads directly. .

Thank you Stephan. What is the harm in operating on threads directly? I mean we generally call various methods on threads such as sleep(), yield(), etc. as well.

[Stephan van Hulst]

Vaibhav Gargs wrote:I mean we generally call various methods on threads such as sleep(), yield(), etc. as well.

None of those methods should be called either. It's not so much that they do a lot of harm (although sleep() can do harm in certain contexts), but using them is a clear indicator that there's something wrong with your overal application design.

People tend to think about "threads" when they should be thinking about "tasks" instead. Tasks are what you want to have done. Threads just happen to be the things to do it. When people use Thread.sleep(), what they actually really want to do is "delay the completion of this task".

Let's say I have an employee working on some sort of job, and I don't want the job to be completed just yet. I don't know, maybe the customer didn't pay yet. Do I tell the employee to go to sleep, or do I tell them to work on something else?

When you call Thread.sleep(), the thread can not be used for anything else. Instead, you should submit the remainder of the task to a ScheduledExecutorService. The remainder will be finished after a certain delay, and in the mean time, the thread is free to work on other stuff.

Similarly, when you call Thread.join(), it means "wait until the thread has stopped running", but what people actually want is "wait until the task this thread was working on has completed". You convey the second meaning using tools such as latches, barriers, conditions and futures.

In high-level modern applications, you should never have any reason to use Thread or any of its methods directly. Thread.interrupt() could be an exception to this rule, but even then you probably don't have to if you're working with methods such as Future.cancel().

[Vaibhav Gargs]

Stephan,

Can you please give me some example scenarios to use CountDownLatch & CyclicBarrier which would make their difference more clear. Thank you in advance!

[Knute Snortum]

This may not be the greatest example, but I'll try.

Say you want to build four wheels for a car.  You don't care what thread or how many are making the wheels; you just need four of them.  Use a CountDownLatch.

Now say you are assembling the car from the frame.  You need to attach the wheels, drop in the engine, and install the seats.  Pretend that these three operations do not depend on each other.  They could start and end at different times, but all three need to be done before you proceed. Use a CyclicBarrier.  This is basically a fancy join operation.

[Knute Snortum]

Here's a complete program that demonstrates a CyclicBarrier from Learning Java, but Niemeyer and Knudsen, https://oreilly.com

import java.io.IOException;
import java.net.URL;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

/**
 * <p>Attribution: from <i>Learning Java 3rd Edition</i>, by Jonathan Knudsen, https://oreilly.com.
 * Changes made by Knute Snortum to bring code up to Java 8.</p>
 * 
 * <p>From the command line, execute the code with two or more valid URLs as command line arguments.
 * For instance:</p>
 * 
 * <pre>java SiteTimer https://google.com https://oreilly.com https://oracle.com</pre>
 * 
 * @author Jonathan Knudsen
 * @author Knute Snortum
 * @version 2017-08-02
 */
public class SiteTimer {
	private CyclicBarrier barrier;
	private List<Result> results = new ArrayList<>();

	private class Result implements Comparable<Result> {
		private Long time;
		private String site;

		public Result(Long time, String site) {
			this.time = time;
			this.site = site;
		}

		@Override
		public int compareTo(Result r) {
			return time.compareTo(r.time);
		}
	}

	private static long timeConnect(String site) {
		long start = System.currentTimeMillis();
		try {
			new URL(site).openConnection().connect();
		} catch (IOException e) {
			return -1;
		}

		return System.currentTimeMillis() - start;
	}

	private void showResults() {
		Collections.sort(results);
		for (Result result : results) {
			System.out.printf("%-30.30s : %d%n", result.site, result.time);
		}
		System.out.println("------------------");
	}

	private void start(String[] args) {
		barrier = new CyclicBarrier(args.length, () -> {showResults(); results.clear();} );

		for (final String site : args) {
			new Thread( () -> {
				while (true) {
					long time = timeConnect(site);
					results.add(new Result(time, site));
					try {
						barrier.await();
					} catch (BrokenBarrierException | InterruptedException e) {
						return;
					} 
				}
			}).start();
		}
	}

	public static void main(String[] args) throws IOException {
		new SiteTimer().start(args);
	}
}