Understanding unsafe publication

Question

In JCIP 16.2 B.Goetz mentioned that

If you do not ensure that publishing the shared reference happens-before another thread loads that shared reference, then the write of the reference to the new object can be reordered (from the perspective of the thread consumign the object) with writes to its fields.

So I would guess that it means that publishing even NotThreadSafe objects with synchronization is enough. Consider the following shared object

public ObjectHolder{
    private int a = 1;
    private Object o = new Object();
    //Not synchronizaed GET, SET
}

//Assume that the SharedObjectHolder published 
//with enough level of synchronization
public class SharedObjectHolder{
    private ObjectHolder oh;
    private final Lock lock = new ReentrantLock();

    public SharedObjectHolder(){
         lock.lock();
         try{
             oh = new ObjectHolder();
         } finally {
             lock.unlock();
         }
     }

     public ObjectHolder get(){
         lock.lock();
         try{
             return oh;
         } finally {
             lock.unlock();
         }
     }
}

Now we have happens-before between writng to oh and returning oh from the method get(). It guarantees that any caller thread observes up-to-date value of oh.

But, writing to oh fields (private int a, private Object o) during construction is not happens-before with wiritng to oh. JMM does not guarantee that. If I'm wrong, please provide a proof-reference to JMM. Therefore even with such publishing, a thread reading oh may observe a partually-constructed object.

So, what did he mean by saying that I provided in a quote? Can you clarify?

Answer 1

If you only read or write oh per the methods above, then the lock aquired by get() will ensure you see all actions up to the release of the lock in SharedObjectHolder's constructor -- including any writes to oh's fields. The happens-before edge you're relying on has nothing to do with the write to oh, and everything to do with writes (including to oh's fields) happening before a lock is released, which happens before that lock is acquired, which happens before reads.

It is possible to see a partially-constructed oh, if you have a thread that reorders get() to happen before the constructor and the write to oh to happen before both of them. That's why the SharedObjectHolder instance needs to be published safely.

(That said, if you can publish SharedObjectHolder safely, I don't see why you couldn't just publish the original oh reference safely.)