[concurrency-interest] Reordering and Immutability

oleksandr otenko oleksandr.otenko at oracle.com
Wed Feb 6 17:21:34 EST 2013

ok. But static initializer itself is also guaranteed to be executed by 
just one thread, and field accesses aren't happening before the static 
initializer is done. So either a lock, or some other way (eg trampoline 
recompilation) to ensure the thread sees the static initializer is done, 
and all member accesses strictly after the initializer is done.

So, if the threads can see uninitialized field (set to null or 0), even 
if the static initializer finished concurrently, then it is an 
interesting consequence I haven't thought of before. But if the threads 
are meant to see the result of static initializer (kind of less 
surprising behaviour), then null cannot be observed in the case at hand.


On 06/02/2013 20:51, David Holmes wrote:
> Sorry I have non-html based mailer so responding inline is not reasonable.
> The implicit initialization of static fields to their default values 
> will always happen-before any thread can see those fields due to the 
> class initialization process. So the reference is either null or a 
> proper reference to an object that may or may not be itself properly 
> initialized. It can never be a random set of bits.
> David
>     -----Original Message-----
>     *From:* oleksandr otenko [mailto:oleksandr.otenko at oracle.com]
>     *Sent:* Thursday, 7 February 2013 3:47 AM
>     *To:* dholmes at ieee.org
>     *Cc:* David Holmes; Yann Le Tallec; concurrency-interest at cs.oswego.edu
>     *Subject:* Re: [concurrency-interest] Reordering and Immutability
>     On 03/02/2013 21:21, David Holmes wrote:
>>     Yann Le Tallec writes:
>>     ...
>>>     (2) Same question with resource declared as "private static Resource
>>>     resource;" (without the "= null") and with the additional assumption
>>>     that Resource is immutable
>>>     - I am told that "Resource resource; can't race whereas Resource
>>>     resource = null; can", but I don't see why they are different from a
>>>     JMM perspective.
>>     There is no difference. "Resource resource;" implicitly sets resource to
>>     null during static initialization of the class.
>     Then it may also return a non-null value that is not even a valid
>     reference, and certainly doesn't necessarily reference a valid
>     Resource instance.
>     Right?
>     Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130206/1607fa72/attachment.html>

More information about the Concurrency-interest mailing list