[concurrency-interest] Concurrent Serialization Pattern

Kevin Condon conivek at gmail.com
Sat Sep 16 21:02:17 EDT 2006

Hi David,

On 9/16/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> So your pattern made the object immune to
> unsafe-publication - though as we have discussed in the context of
> constructors, generally it is not worth the effort to achieve this level of
> thread safety - just ensure you do publish safely.

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.  Wasn't
that the gist of the concurrency puzzle thread and the possibility of
seeing the default value w/o a hb?

> Now somewhere a long the way you decided that your final Lock field needed
> to be transient. That is the part I don't understand as
> ReentrantReadWriteLock is Serializable.

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.

I've thought of 2 possibly better ways to address this than the
readResolve approach, but I'll hold off until it's confirmed that the
problem I'm solving is even real.


More information about the Concurrency-interest mailing list