If two threads both running in respective static constructors perform an operation which would cause the other static constructor to execute, then a deadlock will occur. In Java, the process requires killing. In .Net, one of the threads is chosen as a victim.
Richard > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf Of > Ingo Lundberg > Sent: 30 April 2002 10:02 > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > Hi there, > > I hope it isn’t too late to jump in and ask a few questions. > I don’t now if this thread was about creating singletons to begin with but > my question is about just that. Vance Morrison’s posting was about > singletons anyway. > > How about creating the singleton instance in the static constructor? > Is that bad? > What’s the semantics of the static constructor? > Is it guaranteed to run only once? > Thread safe? > What about static members initiated where they are declared? > Only once? > Thread safe? > What’s wrong with these two classes from a threading perspective. > > TIA > /Ingemar > > public class MySingleton > { > static MySingleton theInstance; > private MySingleton() {} > static MySingleton() > { > theInstance = new MySingleton(); > } > public MySingleton Instance{ get{return theInstance;} } > } > > public class MySingle2 > { > static MySingle2 theInstance = new MySingle2(); > private MySingle2() {} > public MySingle2 Instance{ get{return theInstance;} } > } > > > > On Mon, 29 Apr 2002 14:29:46 +0200, Valery Pryamikov > <[EMAIL PROTECTED]> wrote: > > >Your latest code should work, of course, but using second lock would be > >quite an expensive addition... And you only need a memory write barrier > >between <init stuff> and bNeedInit = false. Using two different > >fNeedInit+fNeedInitInt fields is more efficient solution for lazy init > >problem (you already have mem.barrier during lock release). > > > >Cheers, > >-Valery. > > > >-----Original Message----- > >From: Henk de Koning [mailto:[EMAIL PROTECTED]] > >Sent: Monday, April 29, 2002 2:18 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [DOTNET] lock - how expensive is it to call? > > > >Hmm, I had been thinking of > > > >if (bNeedInit) > >{ > > lock(this) > > { > > if (bNeedInit) > > { > > lock(this) > > { > > <init stuff> > > } > > bNeedInit = false; > > } > > } > >} > > > >I agree with you that there was still a problem in the code I posted > >(although you must admit that it would safely initialize the value of > >variable bNeedInit ;-). About threads, sure they can hop across cpu's. > >However, the point was of course that while a thread is scheduled, it > >will > >run on one cpu only. Context switches surely don't alter the code > >sequence > >being executed ;-). I agree with you on your point that memory access > >from > >one cpu to one mem location is not reordered. That's the rule I was > >referring to. > > > >So, what can we learn from this: never post code from the top of your > >head > >and then respond to emails without rereading what you posted ;-);-). > > > >-- Henkk > > > >----- Original Message ----- > >From: "Valery Pryamikov" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Monday, April 29, 2002 1:34 PM > >Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > > >> BTW: > >> This kind of lazy init problem could be corrected following way: > >> > >> if (fNeedInit) { > >> lock (this) { > >> if (fNeedInitInt) { > >> <init stuff> > >> fNeedInitInt = false; > >> } > >> } //write barrier is performed by lock's release. > >> fNeedInit = false; > >> } > >> > >> Note: second if checks internal fNeedInitInt variable and fNeedInit is > >> updated outside of lock region. > >> (of course we consider that bNeedInit/fNeedInit/fNeedInitInt are not > >> volatile). > >> > >> -Valery. > >> > > > >You can read messages from the DOTNET archive, unsubscribe from > DOTNET, or > >subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
