aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Question related to Thread synchronization. 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 "Question related to Thread synchronization." Watch "Question related to Thread synchronization." New topic
Author

Question related to Thread synchronization.

Hrishikesh Yeshwant Alshi
Ranch Hand

Joined: Dec 06, 2010
Posts: 62

Question IV: (Question form Enthuware)



The explanation given in the enthuware is either incorrect or I failed to understand it. It says …

For each invocation of workWithLocks(), each variable pair is incremented and their values are always equal when the method returns.
The only way a letter could be printed would be if the method workWithoutLocks() was executed between the time the first and the second variable was incremented.
Since the workWithoutLocks() method does not depend on owning any monitor, it can be executed at any time, and the method workWithLocks() cannot protect the atomic nature of its operations by acquiring monitors.
The moral of the story is : It does not matter if a methods does it's job by acquiring monitors or not. What matters is whether ALL the methods that use shared resources do their job after acquiring monitors or not. Because, acquiring a monitor will not prevent any other method which does not use monitors, from accessing the shared resource.


MY DOUBT:

Please observe that the method ‘workWithLocks()’ is actually acquiring the lock on the objects (lock1) and (lock2) and not on ‘this’. What is the use of these locks? How would it prevent the variables i1, i2, j1, j2, k1, k2 from concurrent access i.e liveness failure and safety failure? It is as good as the method ‘workWithLocks()’ is not working with locks.



Write your code as if the person who maintains it is a homicidal maniac who knows where you live.
OCPJP6/SCJP6 86%
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

The Locks are used to avoid Race conditions when multiple threads are trying to access the shared resource- These in no way to prevent the other method to access the shared resource if its not synchronized.

You can try removing the synchronized blocks from the workWithLocks method and see- each time you execute- the values of i1 and i2 will be different. With the synchronized block- we can ensure that i1 and i2 are incremented together.

The explanation given is correct.


Mohamed Sanaulla | My Blog
Hrishikesh Yeshwant Alshi
Ranch Hand

Joined: Dec 06, 2010
Posts: 62

I am sorry, but may I get your attention to the below point?

Observe that the method ‘workWithLocks()’ is actually acquiring the lock on the objects (lock1) and (lock2) and NOT on ‘this’.

The variables i1, i2, j1, j2, k1, k2 are NOT the members of Object lock1 or Object lock2.

Acquiring the lock on Object lock1 or Object lock2 CANNOT prevent threads from accessing variables i1, i2, j1, j2, k1, k2 concurrently.

Further, declaring variables i1, i2, j1, j2, k1, k2 would NOT help either as volatile will ONLY make sure that all the threads will always receive the latest value of these variables.

Am I right?






Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

The moral of the story is : It does not matter if a methods does it's job by acquiring monitors or not. What matters is whether ALL the methods that use shared resources do their job after acquiring monitors or not. Because, acquiring a monitor will not prevent any other method which does not use monitors, from accessing the shared resource.


The above explains everything.

Hrishikesh Yeshwant Alshi wrote:The variables i1, i2, j1, j2, k1, k2 are NOT the members of Object lock1 or Object lock2.


Its not necessary for the shared resource to be part of the object on which they are locking. The whole point of using locks is that- You allow one thread to execute in that block and there by protecting your shared resource. So if you have other methods or other block of code accessing the shared resource- You need to synchronize that block.

Hrishikesh Yeshwant Alshi
Ranch Hand

Joined: Dec 06, 2010
Posts: 62

Thanks much Mohamed .
Its not necessary for the shared resource to be part of the object on which they are locking. The whole point of using locks is that- You allow one thread to execute in that block and there by protecting your shared resource. So if you have other methods or other block of code accessing the shared resource- You need to synchronize that block.



I was under the impression that "It IS NECESSARY for the shared resource to be part of the object on which they are locking." I don't know from where I picked it up. May be it was my own WRONG understanding.

I am happy that the misconception is wiped off.

Thanks much.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question related to Thread synchronization.