wood burning stoves*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Regarding Syncronization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Regarding Syncronization" Watch "Regarding Syncronization" New topic
Author

Regarding Syncronization

kiruthigha rajan
Ranch Hand

Joined: Dec 29, 2011
Posts: 69
Hi i am having a doubt in this program:

there are two threads and each thread acesses the for loop..
does the for loop behaves uniquely for each thread..
for instance the while thread 1(fred) accessing the for loop the value is x=0,1,2..when it sleeps and
thread 2(lucy) is called does the x value will posses previous value used by thread1 OR it will posses its own value of x=0,1,2..


Zeeshan Sheikh
Ranch Hand

Joined: Nov 20, 2011
Posts: 144

This example is from K&B book.

does the for loop behaves uniquely for each thread..

No loop always behave the same way. In the book its explained several time the "bahaviour of the thread is never guaranteed"

If you run that program you will see that thread (fred) runs and it tries to withdraw and goes into sleep mode and then 2nd thread runs and tries to withdraw and eventually you will see that only 50 dollars were in the account and 60 were taken out from the account. Keep reading and she will explain more about this example. YOu have to make it atomic (synchronization will be introduced to resolve this issue.)


MySQL Blog
http://mysqlearner.blogspot.com/
kiruthigha rajan
Ranch Hand

Joined: Dec 29, 2011
Posts: 69
Zeeshan Sheikh wrote:This example is from K&B book.

does the for loop behaves uniquely for each thread..

No loop always behave the same way. In the book its explained several time the "bahaviour of the thread is never guaranteed"

If you run that program you will see that thread (fred) runs and it tries to withdraw and goes into sleep mode and then 2nd thread runs and tries to withdraw and eventually you will see that only 50 dollars were in the account and 60 were taken out from the account. Keep reading and she will explain more about this example. YOu have to make it atomic (synchronization will be introduced to resolve this issue.)


then this implies that if thread(fred) takes x=1 for FOR LOOP then thred(lucy) will take x=2 am i right?
ayush raj
Ranch Hand

Joined: Jan 15, 2012
Posts: 60
Can the two threads started in line 18 and 19 , be viewed as having two separate codes for the run method and it now depends upon the scheduler to call the run method for each threads and allocate the time slice ? Although the behavior of threads is never guaranteed , but i think both the threads for Lucy and Fred will have independent for loops in the run method , starting with the value zero . Am i correct ?

Thanks

Ayush
Helen Ma
Ranch Hand

Joined: Nov 01, 2011
Posts: 451
Yes. When two threads starts at line 18 and 19, they are two pieces of light weighted processes running by JVM . The operating system will do its own processing. For example, in round robbin fashion. Maybe, the operating system let thread 1 run for 1 second, and thred 2 run for 1 second and etc. Maybe , some operating systems let thread 1 run first and then thread 2. Maybe, some operating systems let thread 1 run for 2 second, pause thread 1, let thread 2 run for 3 seconds, pause thread 1, let thread 1 run for another 1 second and etc. We never know how operating system handles the time slice of the thread.

Yes. Both Lucy and Fred execute the run method staring from x=0 to x=4 on their own. x is a local variable in run() method. Lucy has its own copy of x and Fred has its own copy of x. Remember in KB's book, we don't need to synchronize any local variable inside a method because the thread will have its own local variables which won't affect each other.

But both of them are sharing the same AccountDanger instance in this case. Also, makeWithdrawal is not synchronized. Therefore, both of them will withdraw money from the same AccountDanger instance. This is a typical violation of mutual exclusion in operating system.

Correct me if I am wrong in anything.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Regarding Syncronization