C Jay wrote:I also have a sleep(500) in the synchronized code.
C Jay wrote: Hi,
I understand what the sleep(500) does here. The whole point of having this sleep(500) is to allow another thread check on the balance before withdrawal. Let me make this clear. This example is from K&B certification book, with minor modifications. There are 2 threads, both running on the same account. Say Fred enters it first. Fred checks account balance. Balance is more than 10(withdrawal amount). Now before doing a withdrawal, his thread sleeps for 500 milliseconds, so another thread (here Lucy is waiting in the next thread on the same account) can do the same account balance. She should be able to see the balance. Now Lucy's thread sleeps for 500 milliseconds, while runnable Fred thread resumes and continues to make withdrawal... and so on. So the 2 threads have to take turns because:
1. There is a sleep() in between check account balance and withdraw
2. Both the threads use the same account.
C Jay wrote: ... But K&B book has the following result for almost similar code:
Fred making withdrawal. Balance is: 50.0
Fred withdrawal complete. Current balance: 40.0
Lucy making withdrawal. Balance is: 40.0
Lucy withdrawal complete. Current balance: 30.0
And this result is what I am not getting. Does it mean that K&B code is incorrect? I tried using
a. synchronized(this) or
b. synchronized(acct)
instead of synchronized on the method withdrawal (as suggested by other websites for the same code) but still I am not getting the result that the book has printed. I am hoping that some of our ranchers might have tried the same from K&B book for the example above. Did anybody get the same result as what the book says it should?
C Jay wrote:Henry,
I tried changing to sleep(1*60*1000); still for 1 minute Fred only seems to hold the code, and nothing else changes. He withdraws 5 times ( checks balance, 1 minute break window, withdraws amount) before Lucy gets her first turn. I understand that underlying OS/JVM does the scheduling..but 1 minute is long enough for Lucy's thread to get a chance, right? That too..this happens for 5 times..consistently...too strange..
I will see if I can run the code in a different OS, but in the meantime I thought I will update you with what I've tried after your reply.
As already mentioned by Stuart, and reaffirmed by me (in my first response), In your program, the sleep() method is called *with* the lock. Increasing the size of the sleep() will just make the program run longer, Lucy can't run while Fred is holding the lock, regardless of how long you sleep.
If you want the context switch to have a better chance of happening, you will need to sleep when Fred is *not* holding the lock. Move the sleep() method call to outside of the synchronized call, and it will work.
C Jay wrote:
On one hand, SCJP 6: K&B code has the sleep method inside the withdrawal method between the steps of getbalance() and withdraw(amt), and the output shows that Lucy and Fred take turns. -->A
C Jay wrote:
In another page, the same book states that sleep() keeps locks (as you and Stuart had confirmed earlier; Page 740; Methods and Lock status table).-->B
I believe that B is correct, but then my confusion was to the output in A. If sleep does not give the lock, how come Lucy got a chance as in output A?
I hope you understand what I am trying to say here.
C Jay wrote:Hi Stuart and Henry:
instead of synchronized on the method withdrawal (as suggested by other websites for the same code) but still I am not getting the result that the book has printed. I am hoping that some of our ranchers might have tried the same from K&B book for the example above. Did anybody get the same result as what the book says it should? Any light on this is greatly appreciated.. I have been breaking my head with this for the past 48 hours..
....
On one hand, SCJP 6: K&B code has the sleep method inside the withdrawal method between the steps of getbalance() and withdraw(amt), and the output shows that Lucy and Fred take turns. -->A
In another page, the same book states that sleep() keeps locks (as you and Stuart had confirmed earlier; Page 740; Methods and Lock status table).-->B
Well, I have the book. And I can't see the text ( 'it should') you mention. The books says it very clearly in more than one places that with threads ( with unresolved race conditions ), very little is guaranteed.
Thou shalt not try me. Mom 24:7
rubbery bacon. crispy tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|