Re: [DOTNET] lock - how expensive is it to call?

[Henk de Koning]

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
>
> ----- 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.