File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Which approach should I use to synchronize? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Which approach should I use to synchronize?" Watch "Which approach should I use to synchronize?" New topic
Author

Which approach should I use to synchronize?

Swathi Kodeboyina
Greenhorn

Joined: Jul 31, 2012
Posts: 7
I have a



My doubts are as below.

1. I have to synchronize the access to synchMe. If i synchronize only the method changeSynchMe() , the other threads might access synchme variable while one thread is obtaining lock on changeSynchMe()

2. If I have to synchronize all the blocks where synchMe is used, there are multiple blocks which access it and i should synchronize it in multiple places.

3. On which object should I obtain a lock when I am using synchronized() in ClassB?

4. I have read that using synchronized(this) is not advisable. If so, should I use a class lock in case of Class C and Class D?
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1763
    
    7

You could make the synchme member private and add a synchonized protected getter for it if you need thread-safe access to it from subclasses. You could then synchronize the changeSynchme() method to atomically get the current value of synchme, keep track of that value locally, increment synchme's value and finally return the old synchme value as a result. The changeSynchme() method essentially becomes an atomic get-then-increment for synchme and the optional getter still allows thread-safe read-only access from subclasses if you need it.

You could also make the synchme member an AtomicInteger, which offers this atomic behavior out of the box.

If you synchronize on an intrinsic lock, using this as an argument to a synchonized statement or implicitly via synchonized methods, you essentially use a public lock that anyone can synchronize on, which can make it an source of undesired contention, or even allow external code to steal the lock and never release it, either accidentily or on purpose.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Swathi Kodeboyina
Greenhorn

Joined: Jul 31, 2012
Posts: 7
Jelle Klap wrote:

Thanks for the suggestions.

Would this approach have any problems w.r.t to the public lock problems?



I will use this lock in synchronized(lock) everywhere i am accessing synchme variable. How do you think on this approach ?
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1763
    
    7

In a more limited way, because it's declared protected, so the protected access levels apply.
I don't really see any reason to expose the lock at any level, though.

As far as using it to make access thread-safe. It might be suficient, then again it might not be, it depends on the situation.
For instance you could have a getter and a setter for synchme, which both use a synchonized block that uses the lock object you specified. In some situations that would be sufficient to achieve thread-safe behaviour, but in situations where the value set by the setter method depends on the value returned by the getter method, it would not be. Without additional synchronization that would not be an atomic operation. I think that atomic behavior is what you're actually looking for in your ClassC#metho1() and ClassD#method3333(), correct?
Swathi Kodeboyina
Greenhorn

Joined: Jul 31, 2012
Posts: 7
Jelle Klap wrote:


Yes you are right! I want the behavior in the method ClassC#metho1() and ClassD#method3333() to be atomic w.r.t the access of synchMe variable. There are few generic method in ClassB which are used by ClassC and ClassD. These generic methods also access synchme variable. So I thought of the approach to make the lock in ClassB a protected variable and use the same lock in ClassB and its subclasses too.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Which approach should I use to synchronize?