About Question enthuware.ocpjp.v8.2.1312 :
Moderators: Site Manager, fjwalraven
-
- Posts: 7
- Joined: Mon Jul 11, 2016 12:08 pm
- Contact:
About Question enthuware.ocpjp.v8.2.1312 :
Hi there
I think that object DataObjectWrapper cannot be considered as thread safe because its field 'obj' is not final or not volatile. If I am not mistaken without final/volatile field we would have a data race here.
Here is a use case:
1. Thread 1 create the instance of DataObjectWrapper and pass in the constructor some other object.
2. Thread 1 assign it (instance of DataObjectWrapper) to some static field 's'
2. Thread 2 reads the field 's' and see that field is not null
3. Thread 2 reads the value of DataObjectWrapper instance field 'obj' and don't see the value which was passed to the object constructor by Thread 1.
Please explain where am I wrong. Thank you.
I think that object DataObjectWrapper cannot be considered as thread safe because its field 'obj' is not final or not volatile. If I am not mistaken without final/volatile field we would have a data race here.
Here is a use case:
1. Thread 1 create the instance of DataObjectWrapper and pass in the constructor some other object.
2. Thread 1 assign it (instance of DataObjectWrapper) to some static field 's'
2. Thread 2 reads the field 's' and see that field is not null
3. Thread 2 reads the value of DataObjectWrapper instance field 'obj' and don't see the value which was passed to the object constructor by Thread 1.
Please explain where am I wrong. Thank you.
-
- Site Admin
- Posts: 10388
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
In your scenario, it is the variable static s that is causing the race condition. The DataWrapper object itself is thread safe because its data member obj is not being set anywhere else except in the constructor. There is no need for making obj volatile. Volatile is needed if multiple threads change the value of the variable without synchronization.
HTH,
Paul.
HTH,
Paul.
-
- Posts: 7
- Joined: Mon Jul 11, 2016 12:08 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
Could you please provide example in which DataWrapper object will not be thread safe if we add a setter for obj field there.
Last edited by aaaqwert on Tue Jul 12, 2016 4:24 am, edited 2 times in total.
-
- Site Admin
- Posts: 10388
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
This is quite simple actually. Just create two threads that call setObject on the same DataWrapper object reference. Refer to any OCPJP book on this topic. Here is one of the oldest article on this topic: http://www.javaworld.com/article/207674 ... afety.html
-
- Posts: 7
- Joined: Mon Jul 11, 2016 12:08 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
Please explain meaning of this quote in java specification language
from herehttps://docs.oracle.com/javase/specs/jl ... l#jls-17.5final fields also allow programmers to implement thread-safe immutable objects without synchronization.
-
- Site Admin
- Posts: 10388
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
Not really sure what you are asking. It is true that final fields also allow programmers to implement thread-safe immutable objects without synchronization. This is what I said in my previous post as well. synchronization and volatile are two different approaches for thread safely and they are meant for different purposes. They are not interchangeable.
This is not a topic that I can explain to you in a forum post. You will need to go through a good book to understand this topic.
This is not a topic that I can explain to you in a forum post. You will need to go through a good book to understand this topic.
-
- Posts: 7
- Joined: Mon Jul 11, 2016 12:08 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
I am trying to figure out why object which might be seen in thread not fully initialized can be considered as thread safe. First example which was provided is supposed to illustrate that when the object is unsafely published (without synchronization or volatile) it could be seen as partially initialized, which I think is unacceptable for thread safe object.
-
- Site Admin
- Posts: 10388
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1312 :
You are right. Your post forced me to look at the class again and I now agree that the variable has to be final (or volatile). I have updated it now.
thank you for your feedback.
Paul.
thank you for your feedback.
Paul.
Who is online
Users browsing this forum: No registered users and 5 guests