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

[Alexander Klyubin]

Right. I don't know the details of .NET that good. Maybe one can solve 
the dreaded DCL in .NET.

The primary issue I see here is that this simple code bloated 
dramatically. :)

In my code I usually avoid such things until I am REALLY REALLY sure 
that I need that performance increase. I usually use one of the two 
approaches (in the order of preference):

* initialize the singleton instance during class initialization

   private static final Singleton singleton = new Singleton();

* synchronize getInstance method

   lock (typeof Singleton) {
     if (singleton == null) {
       singleton = new Singleton();
     }
     return singleton;
   }

Practice has shown that for 99% of cases this is really good enough 
solution.

Regards,
Alexander Klyubin

Serge wrote:

>>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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>