That's interesting. The relevant guarantee they provide is
2. Type initialization alone shall not create a deadlock unless some code called from a type initializer (directly or indirectly) explicitly invokes blocking operations.
This suggests that the definition of "waiting for" in 2.2.1 considers only chains in which each thread is trying to acquire an initialization lock held by another thread. Waiting on other locks or events appears not to be considered. Thus the deadlock detection algorithm appears to be one step stronger than the Java one, but the approach is otherwise the same.
This gets around Bill's example. It may be better, but I'm not sure how helpful it really is. The above guarantee isn't that meaningful until you specify which library functions are "blocking operations". Since Java string concatenation can use StringBuffer operations which may be synchronized, is it a blocking operation?
Hans
> -----Original Message-----
> From: Jon Skeet [mailto:jon.skeet@peramon.com]
> Sent: Wednesday, March 19, 2003 2:40 PM
> To: Bill Pugh; Boehm, Hans; javamemorymodel@cs.umd.edu; Gilad Bracha
> Subject: RE: JavaMemoryModel: Java Class initialization can deadlock?
>
>
> > 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.
>
> If it's any help, we could have a look at the .NET model for
> resolving this kind of thing. Here's a quote from partition
> 2, section 9.5:
>
> <quote>
> A rough outline of the algorithm is as follows:
> 1. At class load time (hence prior to initialization time)
> store zero or null into all static fields of the type.
> 2. If the type is initialized you are done.
> 2.1. If the type is not yet initialized, try to take an
> initialization lock.
> 2.2. If successful, record this thread as responsible for
> initializing the type and proceed to step 2.3.
> 2.2.1. If not, see whether this thread or any thread waiting
> for this thread to complete already holds the lock.
> 2.2.2. If so, return since blocking would create a deadlock.
> This thread will now see an incompletely initialized state
> for the type, but no deadlock will arise.
> 2.2.3 If not, block until the type is initialized then return.
> 2.3 Initialize the parent type and then all interfaces
> implemented by this type.
> 2.4 Execute the type initialization code for this type.
> 2.5 Mark the type as initialized, release the initialization
> lock, awaken any threads waiting for this type to be
> initialized, and return.
> </quote>
>
> Jon
>
-------------------------------
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