SS.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
construc
Of course another thread (that isn't blocked waiting to lock on the same
object as the lock block )can see provider_, since no thread is blocked
from accessing the Provider property like a static constructor is.
The concern with that and the double-check lock is that the first if
statement (if (pr
The Monitor.Exit generated by the lock statement has an implicit memory
barrier that will flush the CPU write cache at the end of the lock block.
Adding a MemoryBarrier after the assignment to "instance" only guarantees
that cached writes up to that point are flushed to RAM. The only thing
visib
On 7/9/07, Peter Ritchie
<[EMAIL PROTECTED]> wrote:
The Monitor.Exit generated by the lock statement has an implicit memory
barrier that will flush the CPU write cache at the end of the lock block.
You were right and I was wrong - somewhere (AwareLock::LeaveHelper
used by the SyncBlock implemen
' 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# Singl
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
t
Yes, a processor may be doing more than caching, so "flushing cached
writes" may be a bit simplistic in terms of what happens when
Thread.MemoryBarrier is called. But, it only deals with ensuring what the
processor may be doing, not with what the compiler is doing (or has done)
with registers. i.
Which can be made moot by declaring appropriate members "volatile".
I doubt the hyper-volatility Microsoft JITs would not add the memory
barrier at the exit of the constructor. But, it would be nice to know
what's it IS doing...
On Mon, 9 Jul 2007 10:57:27 -0700, Greg Young <[EMAIL PROTECTED]>
w
Peter Ritchie wrote:
>
> It's very clear with respect to CPU caching. Monitor.Enter is an
> implicit
> memory barrier, all CPU cached writes will be flushed to RAM (meant
> specifically for the object being locked; but most processors don't
> have
> that level of granularity so the whole cache is
The Monitor.Exit generated by the lock statement has an implicit memory
barrier that will flush the CPU write cache at the end of the lock block.
Adding a MemoryBarrier after the assignment to "instance" only guarantees
that cached writes up to that point are flushed to RAM. The only thing
visibl
Greg Young wrote:
> In the x86 JIT nearly EVERYTHING is considerred volatile, perhaps the
> others dont follow the spec?
I think the issue in the pre .NET 2.0 days was this: what happens when the
relaxed ECMA memory model meets a processor architecture with a relaxed
memory model (like the IA64 a
The more interesting question in all of this is that even with
completely safe code I cannot be assured by a conforming CLR that my
object is actually ready to be used on my other thread.
"It is explicitly not a requirement that a conforming implementation
of the CLI guarantee that all state upda
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
It seems the controversial point is whether such out-of-order writes
can occur with the .NET 2.0 memory model. Vance Morrison has written
an article [1] where he seems to say no (in this case), so volatile
(or explicit memory barrier) are not needed. Other sources (such as
the MSDN articles cited)
...not with MemoryBarrier within the synchronized block...
Hm, can you explain this a little more? If one adds a write barrier
after construction of the instance, but before assigning the instance
to the field, as Stoyan's original code did [1], doesn't this have the
desired effect of guaranteei
Outside the lock block is a different story, yes. In which case you may
need something like:
Thread.MemoryBarrier(); // flush processor-cached writes.
if (provider_ == null)
{
lock (syncLock_)
{
if (provider_ == null)
{
I instance = Activator
pr
If provider_ is only set in that one place, or if it's set elsewhere and
within(syncLock_) you don't need the MemoryBarrier. Enter guarantees
acquire semantics and does the memory barrier for you (at the start of the
lock, and since nothing else can access provider while in the lock,
there's no n
With regard to compiler optimizations (C#-to-IL or IL-to-native, AKA JIT)
I don't think 335 is clear.
It's very clear with respect to CPU caching. Monitor.Enter is an implicit
memory barrier, all CPU cached writes will be flushed to RAM (meant
specifically for the object being locked; but most pr
On Mon, 9 Jul 2007 10:50:31 +0300, Stoyan Damov <[EMAIL PROTECTED]>
wrote:
>Yes, but your DCL is broken. However, if you rewrite it like this:
>
>if (provider_ == null)
>{
>lock (syncLock_)
>{
>if (provider_ == null)
>{
>I instance = Activator
>Th
This brings us to the interesting point, why is there disagreement?
This is a very clear statement that monitor is indeed a superset of
volatile.
Yes, it is. But AFAIK, the problem is that the non-volatile read at
the beginning of Ron's code might see the assigned _provider member
before the con
"Note that the MSDN patterns and practices article linked previously
[1] suggests to use the volatile keyword. It's from 2002, however, so
it's based on one of the 1.1 memory models. There is a second article
(without date, but it is more recent), which also suggests using
volatile [2]. I have als
Awesome.
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Stoyan Damov
Sent: Monday, July 09, 2007 2:51 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
> protected stati
osition.
rpn
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ron Young
Sent: Monday, July 09, 2007 1:55 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
Yes, thanks.
But is it a
protected static I Provider
{
if (_provider == null)
{
lock (_syncLock)
{
if (provder = null)
provider =
Activator.createfromconfi
internal abstract class BaseManager where I: IEntityProvider
{
private static I _provider = default(I);
private static object _syncLock = new object();
protected static I Provider
{
if (_provider == null)
{
lock (_sy
CED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
Yes, thanks.
But is it a singleton.
internal abstract class BaseManager where I: IEntityProvider
{
private static I _provider = default(I);
private static object _syncLock = new object(
anced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Greg Young
Sent: Monday, July 09, 2007 12:53 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
Ron see previous comments in your other post about gaurentees in ECMA
335 about cctor executio
Behalf Of Miika Mäkinen
Sent: Monday, July 09, 2007 12:23 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [ADVANCED-DOTNET] C# Singleton
Hi guys,
Which singleton implementation do you normally use? I've been using number
five from http://www.yoda.arachsys.com/csharp/singleton.html but r
I believe you are referring to the simpler version of ..
// .NET Singleton
sealed class Singleton
{
private Singleton() {}
public static readonly Singleton Instance = new Singleton();
}
This is ok providing you dont care if beforefieldinit is set. This
will cause the JIT to load the stati
Of Miika Mäkinen
Sent: Monday, July 09, 2007 12:23 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [ADVANCED-DOTNET] C# Singleton
Hi guys,
Which singleton implementation do you normally use? I've been using number
five from http://www.yoda.arachsys.com/csharp/singleton.html but reading
Ron
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Miika Mäkinen
Sent: Monday, July 09, 2007 12:23 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [ADVANCED-DOTNET] C# Singleton
Hi guys,
Which singleton implementation do you normally use?
Hi guys,
Which singleton implementation do you normally use? I've been using number
five from http://www.yoda.arachsys.com/csharp/singleton.html but reading
http://msdn2.microsoft.com/en-us/library/ms954629.aspx I'm understanding
that a simpler implementation works just the same?
Cheers,
Miika
=
32 matches
Mail list logo
