aspose file tools*
The moose likes Threads and Synchronization and the fly likes Does accessing an Object from a synchronized method lock the Object? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Does accessing an Object from a synchronized method lock the Object?" Watch "Does accessing an Object from a synchronized method lock the Object?" New topic
Author

Does accessing an Object from a synchronized method lock the Object?

Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078


Let's say class A and class B both have methods similar to above, they both modify the same Object but do so via synchronized methods. So Class A and Class B have the synchronized methods and both modify Object C. Is it possible then for Class A and Class B to modify Object C from two different threads at the same time, possibly causing problems? As I understand it, the synchronized keyword in a method simply locks the instance (or the class in a static method) which doesn't imply any locks on anything it's accessing, which means anything it modifies that's not private may be modified concurrently by another thread using a different class or instance.

So this means if we want anything to be 'thread-safe' we have to guarantee that it is itself thread-safe and can't be modified by more than one thread concurrently because there's no way for the threads doing the modification to guarantee it? Or would this fix the problem:



Does that only work if the method modifying someObject is itself synchronized? Or does it mean that no other Thread can modify that Object no matter what? If it's the first, does that mean any Object that exposes it's member variables is inherently NOT thread-safe? Obviously final variables of a primitive type would be an exception since they can't be modified, but even if it's final if someone exposed an Object (since it's just a reference) wouldn't that Object then be modifiable by multiple threads at the same time with no way to prevent this?

Or...in other words...for something to be truly thread-safe does an Object have to fully encapsulate everything it uses and not expose ANYTHING that's not a final primitive and only allow modification of them through synchronized methods? Oi, I'm confusing myself.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Boy there are lots of questions here! I'll just answer the most important ones.

Yes, any object with non-private member data is not thread-safe -- for many definitions of "thread-safe", anyway.

The synchronized(someObject) { ... } approach works great, as long as you know that nobody is going to call someObject's methods outside of such a block.

The only was for a class SomeObject to make itself guaranteed threadsafe is to do so internally -- i.e., using synchronized methods, or synchronized blocks inside of it. If you're required to access someObject inside a synchronized block to use it correctly, then there's no guarantee that everybody's going to do that.

Does this hit all the high points?


[Jess in Action][AskingGoodQuestions]
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Pretty much. So it's like I thought, having a lock on an Object doesn't prevent it from being modified outside of a synchronized block, it only guarantees it can't be modified inside of one until the lock is released.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Right.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Does accessing an Object from a synchronized method lock the Object?