Win a copy of Murach's MySQL this week in the JDBC and Relational Databases forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Sybex 829 errata? Are threads hanging on a Cyclic Barrier considered deadlocked?

 
Ranch Foreman
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)

tb864615.OCPJAVASE17PT.c12.026

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.


 
Marshal
Posts: 28123
94
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"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.
 
Bartender
Posts: 3899
43
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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"
 
Paul Clapham
Marshal
Posts: 28123
94
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also the Wikipedia article Deadlock exists, as I should have known.

Wikipedia wrote:In concurrent computing, deadlock is any situation in which no member of some group of entities can proceed because each waits for another member, including itself, to take action...



Which does seem to apply to the question at hand. It's just not your typical deadlock where one thread is waiting for a second thread to release a lock.

But yes, I tend to agree that a different phrase other than "deadlock" would be better in the question.
 
Mikalai Zaikin
Bartender
Posts: 3899
43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, we can talk in terms of "recoverability".

The true deadlock (IMHO) can never be recovered.

And the code above can be recovered for example by some daemon threads



which may be ignored (as main thread ends before t1 and / or t2 even started) if we had 12 Runnable like this



but since the main thread is blocked, the daemon threads will always run and will "programmatically" "recover" the situation.

Just 2 cents...
 
Anil Philip
Ranch Foreman
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mikalai Zaikin wrote:
So, maybe a better answer could be "Code never ends", or from existing options "None of the above"



So the question is in error?
 
Paul Clapham
Marshal
Posts: 28123
94
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anil Philip wrote:So the question is in error?



I wouldn't be so harsh. Like Mikalai I would say that wording option E differently would be helpful.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic