Page 1 of 1

About Question enthuware.ocpjp.v8.2.1764 :

Posted: Tue Jun 21, 2016 10:58 am
by johnlong
Hello

Have a question. Explanation says : "Consider the following situation -
Thread1 tries to execute the first transfer and acquires the lock for account a1. It updates the balance of a1 but before it could acquire the lock for a2, thread2 executes and acquires the lock for account a2. "

How can thread2 acquire lock for account a2? In my understanding, in order for thread2 to acquire lock for account a2, thread has to pass first synchronization block (synchronized(from)), which is locked by thread1.

Could you please explain?

public void run(){
synchronized(from){ -> if it is occupied by thread1
from.setBalance(from.getBalance()amount);
synchronized(to){ -> how can thread2 get here passing above sync. block, which is occupied by thread1
to.setBalance(to.getBalance()+amount);

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Tue Jun 21, 2016 12:04 pm
by admin
One thread is trying to transfer from a1 to a2 and while the other one is transferring from a2 to a1. So when t1 has acquired a lock for a1 and just before it acquires the lock for a2, thread 1 can come along and get the lock for a2. Notice that from and to are switched for t2.

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Tue Jun 21, 2016 12:29 pm
by johnlong
Sorry, still it is not clear. Could you please answer my question
If a1 synchronization block is occupied by thread1, how can thread2 get into synchronization block of a2.
Thread2 has to pass s1 synchronization block in first place.

Code: Select all

public void run(){ 
        synchronized(from){ -> if it is occupied by thread1 
                 from.setBalance(from.getBalance()amount); 
             synchronized(to){ -> how can thread2 get here passing above sync. block, which is occupied by thread1 
                          to.setBalance(to.getBalance()+amount);

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Tue Jun 21, 2016 12:37 pm
by admin
I did answer your question. Please read it again. "from" and "to" accounts are switched for thread 2. That means the "from" variable in thread2 refers to a2 and not a1.

So thread 2 will acquire the lock for a2 in the outer synchronized block.

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Tue Jun 21, 2016 4:08 pm
by johnlong
Sorry, still it is not clear.

How can thread2 acquire lock for a2 (synchronized from block) if lock is already acquired by thread1?

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Tue Jun 21, 2016 9:45 pm
by admin
Ok, I will try again, but first, can you tell me what do you understand by: "from" and "to" accounts are switched for thread 2?

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Thu Jun 30, 2016 3:00 pm
by johnlong
"from" and "to" accounts are switched for thread 2?
Means than thread1 enters "from" block and then enters "to" block, which is opposite for thread2
Thread2 enters "to" block and then "from" block.

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Thu Jun 30, 2016 8:59 pm
by admin
johnlong wrote:"from" and "to" accounts are switched for thread 2?
Means than thread1 enters "from" block and then enters "to" block, which is opposite for thread2
Thread2 enters "to" block and then "from" block.
No, it is the same code that is executed by two threads. So how can one thread enter the inner block before entering the outer block?

The order of execution of code for both the threads is same but the variables are pointing to different objects for both the threads. For thread 1. "from" is pointing to account object A1 so it gets the lock for a1, and for thread 2, the variable "from" is pointing to account object A2, so it gets a lock to a2.
Now, when thread 1 proceed to the inner block, it cannot get a lock to the account object pointed to by the "to" variable (which is pointing to a1) because its lock is already acquired by thread 2.

Re: About Question enthuware.ocpjp.v8.2.1764 :

Posted: Mon Jul 04, 2016 6:48 pm
by johnlong
I see, thanks.
Will examine it again.