> From: Bill Pugh [mailto:firstname.lastname@example.org]
> Sent: Wednesday, March 19, 2003 1:58 PM
> To: Boehm, Hans; email@example.com; Gilad Bracha
> Subject: RE: JavaMemoryModel: Java Class initialization can deadlock?
> At 1:27 PM -0800 3/19/03, Boehm, Hans wrote:
> >3) This can obviously deadlock even with a single thread, so we
> >patch this by detecting the most obvious deadlock case which
> >involves a recursive invocation of class initialization from the
> >same thread. In that case we allow the (partially) uninitialized
> >class to be used instead. This causes some strange behavior, but
> >since most classes presumably contain many methods that rely on only
> >compile-time initialization, it allows some interesting cases to
> >work correctly.
> Actually, the spec already handles the potential for deadlock in a
> single thread.
That was what I was trying to say. The current spec includes a workaround
for the single thread case, which I think we can view as a particularly
weak form of deadlock detection.
> So initialization circularities experienced by a single thread
> can allow a program to see incompletely initialized classes.
> But when experienced by multiple threads, you get deadlock rather
> than incompletely initialized classes.
> So rather than having to worry about two different bad behaviors,
> maybe we should have just one.
That would be nice.
I'm not sure that it's feasible to replace deadlock with reading of uninitialized
data in all cases, since deadlocks can involve all sorts of other mechanisms for
It would clearly be easy to go in the other direction, and just let recursive
initializations deadlock. I currently have very poor intuition for how much
code that breaks. In any case, there doesn't seem to be an easy way to make
that backward compatible. Or did you have a solution in mind?
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT