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

[Valery Pryamikov]

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.