This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes synchronized on extern class object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "synchronized on extern class object" Watch "synchronized on extern class object" New topic
Author

synchronized on extern class object

Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47
Hi @,

Does someone see a problem with this synchronization:



I mean I admit it is awful, but it is thread-safe, right? even no matter whether Foo or Bar are singletons or not


SCJP 1.6 (91%), SCJD
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

As far as Java is concerned, it is identical to every other sync block in all Java code everywhere and everywhen. The only thing that distinguishes one synchronization from another is which object you sync on, but the object itself has zero significance to Java. (And note that, contrary to your subject line, we sync on objects, not references.)

Your comment about singletons vs. not also sounds misguided. Again, Java doesn't care. A lock is a lock is a lock.

On the other hand, as far as how your app will behave, that depends entirely on A) What else syncs on that same lock and B) What else accesses any shared resources that are accessed in those sync blocks.

There's no way to say whether that code snippet is or is not thread-safe. In isolation, that question has no meaning. It can only be answered in the context of every part of your code that falls under the above A and B. In general, though, syncing on the Class object for a different class is quite unusual (I don't think I've ever seen it, in 15 years of Java programming), and it's probably a red-flag for your design.
Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47
Jeff Verdegan wrote:As far as Java is concerned, it is identical to every other sync block in all Java code everywhere and everywhen. The only thing that distinguishes one synchronization from another is which object you sync on, but the object itself has zero significance to Java. (And note that, contrary to your subject line, we sync on objects, not references.)

Yeah, I know that, sorry for my miswording

Jeff Verdegan wrote:On the other hand, as far as how your app will behave, that depends entirely on A) What else syncs on that same lock and B) What else accesses any shared resources that are accessed in those sync blocks.

That's true, I was in a hurry and forgot to mention, that no side code should be considered (assumed multiple threads will just call the doIt() and the resources modified within doIt() are not modified elsewhere)

Jeff Verdegan wrote:In general, though, syncing on the Class object for a different class is quite unusual (I don't think I've ever seen it, in 15 years of Java programming), and it's probably a red-flag for your design.

Exactly, that's my point too I am actually pretty familiar with multi-threading, but I as I saw this for the first time in my life , I was very curious, whether I don't miss something.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Radi Hadzhiyski wrote:That's true, I was in a hurry and forgot to mention, that no side code should be considered (assumed multiple threads will just call the doIt() and the resources modified within doIt() are not modified elsewhere)


Then it should be fine. In theory you could still have problems if multiple classloaders load that Bar class, and the sync block operates on data shared across those classloaders, as they'll have distinct Bar.class objects. That's scenario seems very unlikely in general though.

Jeff Verdegan wrote:In general, though, syncing on the Class object for a different class is quite unusual (I don't think I've ever seen it, in 15 years of Java programming), and it's probably a red-flag for your design.

Exactly, that's my point too I am actually pretty familiar with multi-threading, but I as I saw this for the first time in my life , I was very curious, whether I don't miss something.


Ah, so you inherited that code? Yeah, that's always fun, wondering whether the guy before us knew something we don't know, and had a good reason for doing things that way, or if he just screwed up.

There are a couple of scenarios where I could imagine someone doing that, but even in those scenarios, I'd probably do it differently.

1. Foo is a nested class of bar. You might get multiple different Foo instances, nested in multiple different Bar objects, and you want all their doIt's to sync on the same object. Bar.class is an easy common object to grab. I'd probably use Foo.class though, or a prrivate static final Object member variable in Foo.

2. Bar itself has some static methods that need to share the same lock as Foo.doIt().

If neither of those situations apply, then I don't have another guess as to what the original coder might have been thinking.
Radi Hadzhiyski
Ranch Hand

Joined: Jun 30, 2009
Posts: 47
Thanks for spending some time thinking around this We can close this now.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

You're welcome!
 
 
subject: synchronized on extern class object
 
Similar Threads
Singleton using public constructors?
Problem in passing ArrayList
Synchronozation
synchronized block
Need a single instance of object.