• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

synchronized on extern class object

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for spending some time thinking around this We can close this now.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic