wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread Synchronization Problem 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 "Thread Synchronization Problem" Watch "Thread Synchronization Problem" New topic
Author

Thread Synchronization Problem

Mohit G Gupta
Ranch Hand

Joined: May 18, 2010
Posts: 634

Nikos Blog





Q1Just before the main method exits, the account’s number field is guaranteed to have value 2000.

true
false


answer:false

------------------------------------



Q2Just before the main method exits, the account’s number field is guaranteed to have value 2000.

true
false


answer:true


join method is guaranteed to Blocks the current running thread until this one (the one joining) has finished .


i think answer in both questions should be true

can anyone tell why first is not guaranteed to give true result


OCPJP 6.0 93%
OCPJWCD 5.0 98%
Mohit G Gupta
Ranch Hand

Joined: May 18, 2010
Posts: 634

please moderators help me
Abimaran Kugathasan
Ranch Hand

Joined: Nov 04, 2009
Posts: 2066

Did you checked here?


|BSc in Electronic Eng| |SCJP 6.0 91%| |SCWCD 5 92%|
Mohit G Gupta
Ranch Hand

Joined: May 18, 2010
Posts: 634

This is what happens...
Thread1 comes in first(lets assume) inside the loop, gets the lock, calls getNumber() , releases the lock & immediately gets the lock again and calls setNumber() (because getNumber() is called in the argument.JVM after solving the argument will directly call the method).
This may continue for some time. We can determine it. Depends on the OS. Lets say i=55 has completed, the set number is 55 now.
When the context is switched on to Thread2, it enters its own loop with i=1. It now gets the lock, calls getNumber() (which is now going to return 55 as the Account object is common to both the threads), calls setNumber().
This may again go on for some time. Lets say when thread2's i=25, number in Account is 70.
Steps 1 to 4 goes on again...


i have looked at the answer but i still have a Doubt

It says that there occurs context switch.
if such is the case then why doenot it happen in the code that uses iincrease()
Then,both the programs should return false
Abimaran Kugathasan
Ranch Hand

Joined: Nov 04, 2009
Posts: 2066

mohitkumar gupta wrote:
It says that there occurs context switch.
if such is the case then why doenot it happen in the code that uses iincrease()
Then,both the programs should return false

There are two invocation of method on a single instance, and there are two threads. But, in the second case, you've only one invocation.
Mohit G Gupta
Ranch Hand

Joined: May 18, 2010
Posts: 634

Abimaran Kugathasan wrote:
There are two invocation of method on a single instance, and there are two threads. But, in the second case, you've only one invocation


how is the two invocation or single invocation tend to affect the program ?

setNumber and getNumber are synchronized and so is the increase method,then

why there occurs a context switch.once a thread gets a lock,it calls getNumber method,it releases the lock then again obtains the same lock and calls setNumber ?

How is it possible for the other thread to come in between ??

basically,i am not able to get why there is a context switch ??
Abimaran Kugathasan
Ranch Hand

Joined: Nov 04, 2009
Posts: 2066

mohitkumar gupta wrote:

setNumber and getNumber are synchronized and so is the increase method,then

why there occurs a context switch.once a thread gets a lock,it calls getNumber method,it releases the lock then again obtains the same lock and calls setNumber ?


Here, you've the answer. So the other thread can come in between. That is the way..
 
 
subject: Thread Synchronization Problem