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.)
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
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..
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)
posted 11 years ago
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)