Not necessarily ;-). Memory allocators usually align memory block to the integer boundary (and even to 64 bites boundary), so adding one byte could be not essential for the memory consumption (depending on the object layout and size).
-Valery. -----Original Message----- From: Henk de Koning [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 2:47 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] lock - how expensive is it to call? 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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
