[concurrency-interest] Double Checked Locking in OpenJDK

Joe Bowbeer joe.bowbeer at gmail.com
Mon Aug 13 18:01:31 EDT 2012

For completeness, here is the documentation for the @Immutable annotation
from JCiP, which is more heavily laden than the standard definition, and
leaves nothing to the imagination of paranoid programmers:


The class to which this annotation is applied is immutable. This means that
> its state cannot be seen to change by callers, which implies that
>    - all public fields are final,
>    - all public final reference fields refer to other immutable objects,
>    and
>    - constructors and methods do not publish references to any internal
>    state which is potentially mutable by the implementation.
> Immutable objects may still have internal mutable state for purposes of
> performance optimization; some state variables may be lazily computed, so
> long as they are computed from immutable state and that callers cannot tell
> the difference.
> Immutable objects are inherently thread-safe; they may be passed between
> threads or published without synchronization.


On Mon, Aug 13, 2012 at 2:46 PM, Wolfgang Baltes wrote:

> Immutability and thread safety should be considered essentially orthogonal
> concepts. However, the final keyword can be useful in both.
> Immutability just means that the object cannot be changed after
> instantiation. There are several ways to achieve this, the most obvious
> ones are a) to make a data fields final, and b) not to provide a method
> that changes the values of data fields.
> Thread safe publishing means that, when an object reference is shared
> between threads, all threads see the object only in the same state as the
> thread which has last modified (or instantiated) the object. There are
> different ways to accomplish this, the most obvious ones being to declare a
> fields final or volatile. Final provides the guarantee that a field can
> safely be published to other threads after the constructor that assigns the
> value is finished. If there are multiple fields, than only those that are
> marked final are covered by the guarantee. This is different from volatile,
> where instructions - such as writes to non volatile fields - that appear in
> the code before a write to a volatile field, are guaranteed to be executed
> before the first subsequent read of that volatile field, no matter in which
> thread this read instruction occurs. In the latter case, a non volatile
> field which is never modified by any method may also appear as immutable
> and be published in a thread safe manner.
> Hence, marking a field final makes it immutable and publishable in a
> thread safe manner, if the reference to the object that holds the field is
> published after the constructor is finished.
> Wolfgang.
> On 2012-08-13 13:20, Ruslan Cheremin wrote:
>> Yes, and it is my point -- it's confusing to say "immutable" (which
>> form of?), confusing to say "thread safe" (in which multithreaded use
>> case it is safe?) and even more confusing to say both "immutable and
>> thread-safe" -- because actually there is (==I know) only two ways to
>> reach thread-safe immutability in java: "all fields final", or "all
>> methods sync-ed, including constructors" -- and the second one is very
>> rare.
>> For me "immutable and thread safe" seems to be equivalent to
>> "thread-safe immutable", which, in turn, implies safety for data race
>> publication. How can I claim object as "thread safe immutable", if I
>> can see in several states in multithreaded env.?
>> 2012/8/13 Yuval Shavit:
>>> This class is immutable but not thread-safe absent safe publication:
>>> public class MyImmutable {
>>>      private long val; // not marked final or volatile
>>>      public MyImmutable(long val) {
>>>          this.val = val;
>>>      }
>>>      public int getValue() {
>>>          return val;
>>>      }
>>> }
>>> In the absence of safe publication, a thread is allowed to see:
>>>      - val's default value (0)
>>>      - the value passed to the constructor
>>>      - a word tear in which val contains only the high or low word from
>>> the
>>> value passed to the constructor
>>> On Mon, Aug 13, 2012 at 3:39 PM, Ruslan Cheremin wrote:
>>>> For me it is confusing: java has only one way to have really immutable
>>>> object, and this way also gives you a total thread safety even for
>>>> data race based publication. But then docs refer object as "immutable
>>>> and thread-safe" -- we still can't assume it to be really thread-safe?
>>>> It's a pity, especially because true immutability gives us some
>>>> chances of performance optimization. As in this case -- we do not
>>>> really need .path to be volatile here, if we would assume Path to be
>>>> truly immutable. volatility here required only for ensuring safe
>>>> publishing.
>>>> 2012/8/13 David Holmes:
>>>>> Ruslan Cheremin writes:>
>>>>>> But is there a way to define "safe for data race publishing"? I as
>>>>>> far, as I remember, "immutable and thread-safe" is standard mantra in
>>>>>> JDK javadocs for totally safe objects. j.l.String has same mantra --
>>>>>> and it is safe for any way of publishing. Does you mean, I should
>>>>>> explicitly add "safe even for publishing via data race" in docs? But I
>>>>>> can't remember any such phrase in JDK docs.
>>>>> I don't recall anything in the JDK docs that mention being "totally
>>>>> safe"
>>>>> regardless of publication mechanism. Some classes, eg String, have been
>>>>> defined such that they do have that property (for security reasons). In
>>>>> general neither "thread-safe" nor "immutable" imply
>>>>> safe-for-unsynchronized-**publication.
>>>>> Java Concurrency In Practice (jcip.net) does define additional
>>>>> potential
>>>>> annotations, where @Immutable would indeed capture the requirement of
>>>>> safe-for-unsynchronized-**publication.
>>>>> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120813/f80de30d/attachment.html>

More information about the Concurrency-interest mailing list