> 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