• 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

Unsafe publication of objects.

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Could some one please guide me through the various ways of publishing an object where its thread safety could be compromised. I went through an article, but still have not found a grip on the same. Could some one please direct me to an article where there are a good number of examples on the same!!
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Could you provide a link to the article you've already read, please?

The principle of safe publication is not that complicated; a reference to the published object and the state of that object need to be visible to any thread at the same time. Visibility is the key here.
To achieve this, first the published object must be properly constructed. If that's covered it can be safely published by storing the reference to the object in a volatile field, by storing the reference in an AtomicReference, by storing the reference in a guarded field, by storing the reference in a final field of an object that is itself properly constructed (i.e. from inside the constructor or init block), or by initializing it from a static initializer.

So all you really need to do (but shouldn't) to unsafely publish an object is violate these rules. Starting at object construction, a very obvious way to break the visibility guarantee is letting the this reference escape. What other scenario's can you come up with?

 
Gagan Sabharwal
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jelly for summing it up!

I actually read someone's blog just a few days back, lost that net link.

You have mentioned about storing an object's reference in a static field, if we have say a public static field, will it be thread safe if the object to which this public static field references has even one instance field as non final ?



Will the above line of code be thread safe?I feel it is not, even if its the first thing to happen in class during the time of class loading.

 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Gagan Sabharwal wrote:Thanks Jelly for summing it up!

I actually read someone's blog just a few days back, lost that net link.

You have mentioned about storing an object's reference in a static field, if we have say a public static field, will it be thread safe if the object to which this public static field references has even one instance field as non final ?



Will the above line of code be thread safe?I feel it is not, even if its the first thing to happen in class during the time of class loading.



Access to the ArrayList instance is not thread-safe, but the example does demonstrate one-time safe publication of the instance.
Immidiately after the class that publishes the ArrayList instance is loaded, it's guaranteed that any thread will see it in a consistent state i.e properly constructed and empty.
Though as soon as the ArrayList instance is modified, all bets are off (hence one-time safe publication).
Thread-safety is about more than just the visibility aspect.
 
Ranch Hand
Posts: 1051
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
if you want to achieve a thread safety then you have to implement a high level of synchroniztion in you class.

which can be achieved by making all the methods of your class as synchronized and variables as volatile.

 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Shanky Sohar wrote:if you want to achieve a thread safety then you have to implement a high level of synchroniztion in you class.


No, there are other techniques for achieving thread safety without any synchronization. Using immutable objects is one; using java.util.concurrent is another.

Shanky Sohar wrote:which can be achieved by making all the methods of your class as synchronized and variables as volatile.


If you make all the methods synchronized, there's generally no point to making the variables volatile; it's redundant at that point. Further, making all methods synchronized does not guarantee thread-safety - careful analysis is still required.

Also, none of these comments has anything to do with the topic of this thread, other than being about thread safety. There are many other random comments that we could make about thread safety - some of them might even be true. ;) But let's remember that the original poster was talking about unsafe publication of objects.
 
Shanky Sohar
Ranch Hand
Posts: 1051
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh yes..i misunderstood the post..
 
Shanky Sohar
Ranch Hand
Posts: 1051
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

No, there are other techniques for achieving thread safety without any synchronization. Using immutable objects is one; using java.util.concurrent is another.


yes this is right there are so many ways for that.

If you make all the methods synchronized, there's generally no point to making the variables volatile; it's redundant at that point. Further, making all methods synchronized does not guarantee thread-safety - careful analysis is still required.


i think in thread nothing is guaranteed even how much analysis we do..we can try our best but even sometimes JVM reacts in a very different way

Also, none of these comments has anything to do with the topic of this thread, other than being about thread safety.



I agree,i misunderstood the post earlier.

OKay lets come to original poster now..
 
Mike Simmons
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Shanky Sohar wrote:i think in thread nothing is guaranteed even how much analysis we do..we can try our best but even sometimes JVM reacts in a very different way


Mmmm, I think it is possible to write code that is guaranteed to be thread-safe. It's just difficult, unless you're able to use immutable objects. Then it's easy.
 
reply
    Bookmark Topic Watch Topic
  • New Topic