[Mono-list] Class library developers: locking issues to keep in mind

[Serge]

> Now, what happens is that this
> thread does NOT perform an explicit read barrier
> and hence may end up
> with incompletely initialized singleton instance.

Well, I see your point.
This situation is possible when JIT inlines constructor's body and reorders
instructions so that object reference is non-null before constructors body
is executed;
Well, under .NET we could ensure valid execution sequence by disabling
inlining and using Create helper as I described in previous posts.
Hmm, it seems using volatile is ineffective here.
But I think applying the following patches should help (see previous post):
1) Extra check in the getter after initializer;
2) Extra thread fork/join in RealInit (all memory will be flushed upon
termination);
3) Using non-inlined helper to create singleton;
To ensure singleton and initializer will be created in the correct order we
could use dummy check for non-null value returned by helper, such as:
   if (singleton == null) {
      singleton = Create ();

      // This dummy check ensures that JIT
      // won't place initializer's constructor
      // before singleton creation
      if (singleton != null)
         initializer = new Call (DummyInit);
   }
Perhaps it's also needed to move DummyInit creation into non-inlined helper.
The above fix will ensure that singleton will be only visible when it's
fully constructed;
This still implies that RealInit could be called more than once, but at
least for any given thread it's guaranteed to be called only once.

As for Java, there is no way to explicitly disable inlining, right?
So perhaps, for Java it's just as hopelessly broken as DCL.
Maybe spawing separate thread for the helper will help?

What do you think?

Sergey