Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Thread-safe objects

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


The explanation says:
"Objects of this class are thread safe but you cannot say anything about the objects wrapped by this class."

How to determine whether a class's objects are thread safe? I don't see any 'synchrnozied'.

Source:Enthuware
[ May 19, 2007: Message edited by: M Krishnan ]
 
author
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

"Objects of this class are thread safe but you cannot say anything about the objects wrapped by this class."



Quote frankly, it is thread safe because there are no race conditions. There is only a getObject() method, which returns the object, period. You can call this method, in any number of threads, in any order, and it will return the same object, everytime.

How to determine whether a class's objects are thread safe? I don't see any 'synchrnozied'.



Two points. Having something "synchronized" does not mean that it is thread safe. Not having something "synchronized" does not mean that it is not thread safe.

There is no easy answer to "determine" whether something is thread safe (that is guaranteed) -- except that with enough practice, you will get better at it.

Henry
 
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Couldn't get it why it's thread safe. First of all two different threads can call the constructor at the same time. Secondly as the Object return is not immutable then it is prone to concurrent acess by multiple threads.
 
Henry Wong
author
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

First of all two different threads can call the constructor at the same time. Secondly as the Object return is not immutable then it is prone to concurrent acess by multiple threads.



No. It is not possible for two threads to call the constructor, for the *same* instance, at the same time. In fact, it is not possible for two threads to call the constructor for the same instance, period. And there is nothing in the constructor (or the getObject() method) that will share anything between instances.

Secondly as the Object return is not immutable then it is prone to concurrent acess by multiple threads.



Yes, but if you reread the original quote. It explicitedly, said that it "cannot say anything about the objects wrapped by this class". In other words, it is refering to the thread safety of its methods -- not the thread safety of the usage of the object that it returns.

Henry
 
Anupam Sinha
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gosh!!! What was I thinking when I said calling the constructor multiple times.

Actually I meant public Object getObject() method.

Thanks for the reply.

Still there's something I am unable to understand.

When you say
Objects of this class are thread safe but you cannot say anything about the objects wrapped by this class."

What is Objects of this class. It's instances or it's instance variables? It should be instances I would say. Let's consider both the case:

If it's instances would it be wise enough to say the class is thread safe but it's instance variables are not.

If it's instance variables I think that now that we have passed the reference of the variable into the constructor it is now a variable of the class and it again wouldn't be correct to say that the class is thread safe.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Going back to the beginning here, I don't think that objects of this class are thread-safe. Because the field obj is not final, and there's no synchronization or use of volatile, there's no guarantee that the value set for obj in the constructor will be seen by all other threads, even after the constructor completes. It's possible for another thread to get a reference to this object and see obj == null. Strange, but true. JLS 17.5 shows a similar example in which the final field x is guaranteed to have been initialized, but the non-final field y is not. Fundamentally, this class is not thread=safe.

However, it's unlikely that the SCJP exam will ask questions related to exact understanding of the Java memory model. So you could probably skip this if you like.

[Anupam Sinha]: What is Objects of this class. It's instances or it's instance variables?

"Objects of this class" means "instances of this class". Same thing.

[Anupam Sinha]: If it's instances would it be wise enough to say the class is thread safe but it's instance variables are not.

Well I think the class is not thread safe because the instance variable obj is not adequately protected. But aside from that, I think it would be more accurate to say that the objects referenced by the instance variable are not necessarily thread-safe. The variable itself is almost thread-safe; it would be completely thread-safe if it had been declared final. But the object it points to... we don't know anything at all about that, so it should be assumed to be not thread-safe.
[ May 20, 2007: Message edited by: Jim Yingst ]
 
And inside of my fortune cookie was this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic