Whereas your solution would increase object size for each and every instance ...
Now I'm pushing it, I now ;-);-) -- Henkk ----- Original Message ----- From: "Valery Pryamikov" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 29, 2002 2:34 PM Subject: Re: [DOTNET] lock - how expensive is it to call? > You right here:-). > > -----Original Message----- > From: Henk de Koning [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 2:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] lock - how expensive is it to call? > > Would be expensive for exactly one call (out of 300.000). > > -- Henkk ;-) > > ----- Original Message ----- > From: "Valery Pryamikov" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, April 29, 2002 2:29 PM > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > 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 > > > > 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.
