File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Threads" Watch "Threads" New topic
Author

Threads

Dishi Jain
Ranch Hand

Joined: Jan 16, 2011
Posts: 46



What will be account number field's maximum value?
Sandra Bachan
Ranch Hand

Joined: Feb 18, 2010
Posts: 434
Dishi Jain wrote:

What will be account number field's maximum value?



Please tell us what output you get when running the code. Is this output different than what you think the output should be?


Marriage Made in Heaven
http://www.youtube.com/user/RohitWaliaWedsSonia
Dishi Jain
Ranch Hand

Joined: Jan 16, 2011
Posts: 46

Sometimes the loop ends with account number value = 2000 but sometimes it ends with value less than 2000 for eg. 1999.
According to me every time the last running thread should stop with account number value = 2000 but no less.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Dishi Jain wrote: Sometimes the loop ends with account number value = 2000 but sometimes it ends with value less than 2000 for eg. 1999.
According to me every time the last running thread should stop with account number value = 2000 but no less.


The place to focus on here is this line...



Basically, the getNumber() method is synchronized, and hence, the call to the method is atomic; the setNumber() method is synchronized, and hence, the call to the method is atomic.

However, there is no synchronization that spans both calls simultaneously, and hence, the complete expression is not guaranteed to be atomic. It is possible for one thread to read a number (say number 42), increment it, but before it can set the new number (43), the other thread reads the same number 42.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Dishi Jain
Ranch Hand

Joined: Jan 16, 2011
Posts: 46

Henry Wong wrote:
Dishi Jain wrote: Sometimes the loop ends with account number value = 2000 but sometimes it ends with value less than 2000 for eg. 1999.
According to me every time the last running thread should stop with account number value = 2000 but no less.


The place to focus on here is this line...



Basically, the getNumber() method is synchronized, and hence, the call to the method is atomic; the setNumber() method is synchronized, and hence, the call to the method is atomic.

However, there is no synchronization that spans both calls simultaneously, and hence, the complete expression is not guaranteed to be atomic. It is possible for one thread to read a number (say number 42), increment it, but before it can set the new number (43), the other thread reads the same number 42.

Henry


Thanks Henry,

I get it that why the value might be less than 2000
But now when the previous thread will come back, will it set the account number value which it gets last time..??
And everything what the other thread has done will be lost?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Dishi Jain wrote:
But now when the previous thread will come back, will it set the account number value which it gets last time..??
And everything what the other thread has done will be lost?


Not sure what you are asking? Are you asking if there are cases where it might be more than 2000?

Henry
Dishi Jain
Ranch Hand

Joined: Jan 16, 2011
Posts: 46

Henry Wong wrote:
Dishi Jain wrote:
But now when the previous thread will come back, will it set the account number value which it gets last time..??
And everything what the other thread has done will be lost?


Not sure what you are asking? Are you asking if there are cases where it might be more than 2000?

Henry


No. I mean if :

1. Thread_0 upon getNumber() retrieves 42 and then leaves the lock.
2. Then Thread_1 comes which also retrieves 42, and sets it 43 and runs for next 7 times increasing number value upto let say 50 and now leaves the lock.
3. Now Thread_0 is back.

In above scenario will the number field will again be set as 43 by Thread_0, since what it read lastly was 42, making the other thread losing its changes. ??
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Dishi Jain wrote:
In above scenario will the number field will again be set as 43 by Thread_0, since what it read lastly was 42


yes
Dishi Jain
Ranch Hand

Joined: Jan 16, 2011
Posts: 46

Henry Wong wrote:
Dishi Jain wrote:
In above scenario will the number field will again be set as 43 by Thread_0, since what it read lastly was 42


yes


Thanks Henry
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads