Thanks for that, will have a look.
Thanks for all the info everyone has posted as well, very interesting to
read and good references to further material.
Ron
----- Original Message -----
From: "Kamen Lilov" <[EMAIL PROTECTED]>
To: <ADVANCED-DOTNET@DISCUSS.DEVELOP.COM>
Sent: Monday, July 09, 2007 8:15 PM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
A theme beaten practically to death in several different places.
You may want to check my series of posts on multithreading, a lot of
ground
has been covered there.
http://www.delera.com/blog/?cat=2
(Although, on a second look, guys who post here seem to have gone 'waaaay
beyond the basics' and my articles / posts may be old news to them)
Kamen
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Greg Young
Sent: Monday, July 09, 2007 9:29 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
is looking at a work in progress. For the DCBL pattern - if something
(compiler, processor, cache) is reordering write operations inside the
lock,
there is a chance the cheating thread might think the singleton is fully
constructed even though all of the writes from the singleton's ctor have
yet
to be "published" for other threads to see.
Yes and this is possible no matter what you do.
"It is explicitly not a requirement that a conforming implementation
of the CLI guarantee that all state updates
performed within a constructor be uniformly visible before the
constructor completes. CIL generators can
ensure this requirement themselves by inserting appropriate calls to
the memory barrier or volatile write
instructions."
On 7/9/07, Scott Allen <[EMAIL PROTECTED]> wrote:
Fabian wrote:
>
> But isn't the point (and also the issue the barrier tries to solve)
> that code from outside the lock actually does access _provider in the
> double-checked locking pattern? So "nothing else can access provider
> while in the lock" seems not to be true, or is it?
>
Yes, I think of the scenario this way:
There is a protocol to follow when working with shared memory. The
protocol
is to take the lock, then read or write shared memory, then release the
lock. As long as all the threads working with the same shared memory
follow
this protocol there is no issue with respect to the how other threads
"see"
the ordering of reads and writes inside the lock.
Code like the double-check lock pattern is trying to gain performance by
cheating and circumventing the standard protocol. The code peeks at
shared
memory without taking a lock. At that point, the ordering of the memory
operations inside the lock becomes extremely important. The cheating
thread
is looking at a work in progress. For the DCBL pattern - if something
(compiler, processor, cache) is reordering write operations inside the
lock,
there is a chance the cheating thread might think the singleton is fully
constructed even though all of the writes from the singleton's ctor have
yet
to be "published" for other threads to see.
--s
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
--
Studying for the Turing test
===================================
This list is hosted by DevelopMentorR http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
