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
