[concurrency-interest] Concurrent Serialization Pattern

David Holmes dcholmes at optusnet.com.au
Sun Sep 17 20:00:22 EDT 2006


Hi Kevin,

> Maybe I've misunderstood the JMM.  I was under the impression that
> non-final field values set during deserialization and construction
> would be in a data race unless a happens-before trigger is introduced.
>  This would be true even if the object were "safely published", which
> I take to mean that no reference to the object is made accessible to
> other threads until construction/deserialization is complete.

Safe publication means more than construction/deserialization being
"complete" it means that you establish a happens-before relationship between
the construction/deserialization and any subsequent use.

> If I've correctly understood the JMM on this (and I guess the verdict
> is still out on that), then the same locking for "normal" access must
> be used during construction, serialization, and deserialization.  Thus
> my quandry, since I can't use a serialized lock object until after
> it's been deserialized.  But then it's too late to use it as the hb
> trigger for the other values already deserialized with it.  That's the
> problem I'm trying to solve.

You must set up the following:

construction/deserialization happens-before publication happens-before
subsequent-use

If the "publication" phase involves no synchronization (ie is unsafe
publication) then it is as you have stated - the same synchronization
mechanism needs to be used in deserialization and subsequent use so that the
publisher and user have "synchronized" appropriately. So yes, even if the
lock is serialized you would still need to use custom deserialization to
actually use the lock. So your readObject could be:

    defaultReadObject();
    lock.writeLock().acquire();
    lock.writeLock().release();

However if you use safe-publication then the custom deserialization is not
needed.

Does the above clarify things?

Cheers,
David Holmes



More information about the Concurrency-interest mailing list