I thought that threads must be mutually dependent upon each other to be deadlocked.
Each contending for a resource that the other is holding onto.
But Boyarsky-Selikoff also calls threads hanging on a Cyclic Barrier, deadlocked.
Is that correct?
Here is the question: (I thought the answer is F None of the above)
What is the output of the following application?
A. Jump! is printed once, and the program exits.
B. Jump! is printed twice, and the program exits.
C. The code does not compile.
D. The output cannot be determined ahead of time.
E. A deadlock is produced at runtime.
F. None of the above.
You Answered Incorrectly.
The code compiles without issue. The main() method creates a thread pool of four threads. It then submits 10 tasks to it. At any given time, the ExecutorService has up to four threads active, which is the same number of threads required to reach the CyclicBarrier limit. Therefore, the barrier limit is reached twice, printing Jump! twice. While eight of the tasks have been completed, two are left running. Since no more tasks will call the await() method, the CyclicBarrier limit is never reached, and a deadlock is encountered at runtime, with the program hanging indefinitely. For this reason, option E is correct.
"Everybody on the web" seems to agree that "deadlock" is like this, although you won't find the JLS providing a definition:
Deadlock in Java is a situation where two or more processes are waiting indefinitely for one another's action.
Deadlock in java is a programming situation where two or more threads are blocked forever.
Deadlock describes a situation where two or more threads are blocked forever, waiting for each other.
I don't know whether those are equivalent to your term "mutually dependent", but let's see how they work here. There are two threads waiting for the CyclicBarrier to let them pass, and the CyclicBarrier is waiting for two other threads which don't exist and never will.
So one of those definitions (the middle one) describes this situation. The other two don't, because they don't admit the possibility that processes will wait for other processes which don't and never will exist.
But I don't care for this kind of logic-chopping, otherwise we'd have to have (and learn) another word to use for this case. I'd use "deadlock" because there are processes which are permanently blocked.
I tend to agree with you because the classic example of a deadlock involves two threads interlocking with each other by using 2 locks.
The code just shows a thread waiting for a finish on a blocking method of a common resource.
So, maybe a better answer could be "Code never ends", or from existing options "None of the above"