• 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

Consuming no CPU cycles

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.)
 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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)

Regards,
Alex
 
David Coppens
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
 
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic