Re: Another DCL-like approach, correct or broken?

From:

Piotr Kobzda <pikob@gazeta.pl>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 10 Aug 2008 10:30:46 +0200

Message-ID:

<g7m8vm$kp5$1@inews.gazeta.pl>

Pavel wrote:

I am not sure that the "second" thread (that is, the thread that saw a
not-null reference on valueHolder outside of the synchronized block)
falls under the definition ("A thread that can only see a reference to
an object after that object has been completely initialized"). Remember
that the assignment to a non-volatile (and not final, but this is
besides the point) field `valueHolder' can happen before the
initialValue() finished its work -- from the point of view of the second
thread as it does not perform a read memory barrier.

You right, valueHolder seems to be improperly published, thus it don't
falls into the definition. Thanks!

To make it working, valueHolder is required to be volatile. Which, in
turn, makes the idea of using final semantics pointless here -- the same
effect may be achieved using just classic DCL.

Fortunately, in the "DCL-like" approach 'FixedValueRef' instance seems
to be /completely initialized/ before publication. Do you see any
publishing problem there?

piotr