>Interesting bits
>
>quote
>
>The main disadvantage of this implementation, however, is that it is not safe for multithreaded environments. If separate threads of execution enter the Instance property method at the same time, more that one instance of the Singleton object may be created. Each thread could execute the following statement and decide that a new instance has to be created:
>
>
>if (instance == null)
>Various approaches solve this problem. One approach is to use an idiom referred to as Double-Check Locking [Lea99]. However, C# in combination with the common language runtime provides a static initialization approach, which circumvents these issues without requiring the developer to explicitly code for thread safety.
>
>unquote
>
>Update: Cases do exist, however, in which you cannot rely on the common language runtime to ensure thread safety, as in the Static Initialization example
>
>I surrender

No batlle :-}
In trying to discover a VB.net alternative to volatile I found this
:http://msdn.microsoft.com/en-us/library/system.threading.thread.memorybarrier(v=VS.100).aspx

Now my head hurts and I'm going to stop :-}
>______
>
>>This looks like the 'super-safe' C# implementation:

public sealed class Singleton
>>{
>>   private static volatile Singleton instance;
>>   private static object syncRoot = new Object();
>>
>>   private Singleton() {}
>>
>>   public static Singleton Instance
>>   {
>>      get 
>>      {
>>         if (instance == null) 
>>         {
>>            lock (syncRoot) 
>>            {
>>               if (instance == null) 
>>                  instance = new Singleton();
>>            }
>>         }
>>
>>         return instance;
>>      }
>>   }
>>}

(from http://msdn.microsoft.com/en-us/library/ff650316.aspx). Only problem is that VB doesn't have 'volatile' :-{
>>
>>
>>>>OK, but that could happen anywhere/anytime ... IOW, after the lock as well as before it.
>>>
>>>Which is why I would always put the expensive lock before accessing oApp.lInitialize
>>>
>>>_________________
>>>>>Didn't say you made it up
>>>>
>>>>I know, I was joking.
>>>>
>>>>>Just thought that in case something can reset oApp.lInitialize - for whatever reason - the first test may think it's initialized and when it executes the next line it isn't anymore. ie, as long as nothing resets oApp.lInitialize, you are right.
>>>>
>>>>OK, but that could happen anywhere/anytime ... IOW, after the lock as well as before it.
>>>>
>>>>>But wouldn't a static initializer be more clear in this case ?
>>>>>

>>>>>private/public static Dictionary TheDictionary = LoadDataDictionary() ; // as long as LoadDataDictionary()  returns a dictionary
>>>>>

>>>>
>>>>Probably ... but we don't know how Michel has implemented the LoadDataDictionary() method, he hasn't said.
>>>>
>>>>~~Bonnie