The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Consuming no CPU cycles 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 "Consuming no CPU cycles" Watch "Consuming no CPU cycles" New topic

Consuming no CPU cycles

David Coppens

Joined: Oct 24, 2007
Posts: 17
Hi all,

Having noticed a deadlock in my code I have went through this forum reading for suggestions on locking.

However, there seems to be a discussion about using notify of notifyAll in combination with a wait on some locked object.

Everyone is concerned about the requirement that no CPU cycles should be consumed when attempting to lock some record that is already locked.

If you use the wait method to do this waiting for the unlock of the record you can never guarantee that no CPU cycles are consumed.
I quote from Java's documentation of the wait method:

As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop.

So, since these spurious wakeups can occur we can never ever guarantee that no CPU cycles are used when we use the wait method.

Any comments on this, I might be far off.

How would we do the locking without using wait/notifyAll/notify ?

SCJA (94%)<br />SCJP (84%)<br />SCWCD (84%)
R van Vliet
Ranch Hand

Joined: Nov 10, 2007
Posts: 144
Originally posted by David Coppens:

How would we do the locking without using wait/notifyAll/notify ?

Well, ignoring the java.util.concurrency packing, which is more a different way to do the same than an actual alternative, you cant do the locking without wait/notify so i wouldn't worry about potentially using cpu cycles in the cases where a thread is woken up prematurely unless it's due to a logical error in your own code (i.e. notify() calls when the lock on that record isn't actually released etc.)
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 443

The Java spec never guaranteed not to consume CPU cycles when trying to acquire a lock, so your right you can't guarantee it so you have to break the must. Basically they want you not to 'spin' acquiring alock , so use wait / notify and just comment.

They want you not to spin as surely thats not efficient (which is a half truth).... but if your using Java 1.6 (which they didn't say you couldn't (I think)) your JVM locks could employ adaptive spinning anyway behind the scene and eat some CPU cycles (because that might happen to be more efficient).. so unless your going to JNI into C++ (and possibly implement your own threading model) your knackered ;-) . At least spurious thread wake up is supposed to be rare ;-)

Basically just read that line as don't go into a tight loop continuously testing some variable to be set (i.e. wait/notify or 1.5 concurrent utilities are good) and comment your choices.

"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516

yeah, this is a tough one.. I finally decided to implement a simple lock/unlock and use notifyAll..

To a certain extent, if the threads were each waiting on something exclusively linked to the record they want to lock, then I believe you could use "notify".
However, in my design they all wait on the same object before they can try to lock a record).. I use notifyAll.. Notify could introduce deadlock if the resources getting notified does not act on it..

you can check these 2 posts also:
notify vs notifyAll
Multiple Notification Objects

I did not see others assignment, however mine mentions "giveup CPU until desired resources" and not "desired record". So if I consider my "locking map" to be the resource, I believe I meet the requirement. (little far fetch I know , but documentable in choices.txt)

David Coppens

Joined: Oct 24, 2007
Posts: 17
My assignment also states 'desired resource'.

I also will go with the wait/notifyAll approach and lock on a map mapping records to cookies (my assignment has cookies). So I should be safe (ignoring the spurious wakeups)
I agree. Here's the link:
subject: Consuming no CPU cycles
It's not a secret anymore!