• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown
Bartenders:

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

 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
author and iconoclast
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right.
reply
    Bookmark Topic Watch Topic
  • New Topic