File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Waiting Thread Queue or notifyAll() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Waiting Thread Queue or notifyAll()" Watch "Waiting Thread Queue or notifyAll()" New topic

Waiting Thread Queue or notifyAll()

Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
Hello Ranchers,

As you know, the interface provided with the assignment specifies the following lock method (or something similar to it):My concern lies with the sentence that states, "the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked." Now this subject has come up several times in this forum, and usually the general consensus is to use notifyAll() in the unlock method to wake up all waiting threads so they can check to see if the record they are waiting for is available. However, this technically does consume some CPU cycles, albeit a very small amount.

In Steve's Post, he outlines a waiting thread queue that he used to ensure that no CPU cycles were consumed until the specific record that a thread was waiting for is unlocked. He also received a perfect score in his locking. Personally, I think the concept of a waiting thread queue is an absolute must in a real world application. But I have always thought that it would be outside the scope of this assignment.

Any thoughts?

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Paul,

My aim was also to wake up threads only when the record lock they were waiting for had become available, thus wasting no CPU cycles. I didn't have a queue though as Steve describes, but I would just use notify to wake up a client waiting for the record lock.
Sadly, I made a little error due to which in a special case threads would never be woken up (see The mysterious 65/80 locking score).

The general consensus in that discussion thread seemed to be that using notifyAll to wake up all or many clients was safer and therefore preferrable over a (slightly) more efficient approach.

For the assignment I think it is indeed beyond the scope; you can pass with 80/80 using a simple approach. It depends on your personal pride how complex you want to make it...


Steve Taiwan
Ranch Hand

Joined: Jul 01, 2003
Posts: 166
Dear Paul.

In fact, my version 1 used notifyAll and wait to implement locking.
However, every time I saw "consumes no CPU cycles", I felt very very uncomfortable to implement locking by using notifyall and wait. Every time I saw other javaranchers got only 44/80, I thought I could fail by using only nofityall and wait. Finally I decided to implement locking by using thread queue and then I can ensure that when SUN uses multi threads to test my, my does not fail. Basically speaking, I think it is a decision that SUN wants us to make.

Thread queue is much safer but more complicated for a junior programmer. NotifyAll is easier but harder to controll thread behaviors.

Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
I agree. Here's the link:
subject: Waiting Thread Queue or notifyAll()
It's not a secret anymore!