thread safe singleton pattern (as a property)

Mountain Bikn' Guy <vc@attbi.com > wrote:

Is the second version shown below better? I couldn't locate enough info
about [MethodImpl(Meth odImplOptions.S ynchronized)] in order to tell.

It's the equivalent of doing:

lock (this)
or
lock (typeof(MyClass ))

round the rest of the method, I believe. I don't believe it
particularly helps in this case.

The first version is *probably* safe due to MyClass being volatile, but
I wouldn't like to say for sure. However, there are fortunately simpler
and definitely reliable versions:

http://www.pobox.com/~skeet/csharp/singleton.html

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Thanks Jon! Your page is very informative!
Mountain

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Mountain Bikn' Guy <vc@attbi.com > wrote:

Is the second version shown below better? I couldn't locate enough info
about [MethodImpl(Meth odImplOptions.S ynchronized)] in order to tell.

It's the equivalent of doing:

lock (this)
or
lock (typeof(MyClass ))

round the rest of the method, I believe. I don't believe it
particularly helps in this case.

The first version is *probably* safe due to MyClass being volatile, but
I wouldn't like to say for sure. However, there are fortunately simpler
and definitely reliable versions:

http://www.pobox.com/~skeet/csharp/singleton.html

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jon,
You mention the following:
"There are complications if one static constructor invokes another which
invokes the first again."

I have run into this problem (or a very similar one) quite frequently,
actually, using the first singleton pattern I posted. Specifically, I have
seen cases where a threadsafe singleton created in a situation where the
static constructors which refer to each other in a cycle then seemingly
contains two different values in one field, depending upon whether that
field is accessed by the other singleton or some third object. Note that I
witnessed this even thought I don't explicity use a static constructor in my
singleton pattern.

Also, you mention "It still doesn't perform as well as the later
implementations " in regard to your 3rd example. However, I assume that
whenever you are mentioning performance on this page, you are referring only
to laziness. (I ready your excellent discussion on your "beforefieldinn it"
page, which led me to understand that laziness != better performance in all
situations -- and that also led me to ask you to clarify that the word
performance on your singleton page refers strictly to laziness).

Regards,
Mountain

Mountain Bikn' Guy <vc@attbi.com > wrote:

You mention the following:
"There are complications if one static constructor invokes another which
invokes the first again."

I have run into this problem (or a very similar one) quite frequently,
actually, using the first singleton pattern I posted. Specifically, I have
seen cases where a threadsafe singleton created in a situation where the
static constructors which refer to each other in a cycle then seemingly
contains two different values in one field, depending upon whether that
field is accessed by the other singleton or some third object. Note that I
witnessed this even thought I don't explicity use a static constructor in my
singleton pattern.
I may not have been very precise here - I'll check later on. You don't
need to be using an explicit static constructor to get this kind of
behaviour, just static initialization of some description.
Also, you mention "It still doesn't perform as well as the later
implementations " in regard to your 3rd example. However, I assume that
whenever you are mentioning performance on this page, you are referring only
to laziness. (I ready your excellent discussion on your "beforefieldinn it"
page, which led me to understand that laziness != better performance in all
situations -- and that also led me to ask you to clarify that the word
performance on your singleton page refers strictly to laziness).

Nope, it's not to do with laziness (and as you've inferred, enforcing
strict laziness can reduce performance). It's to do with how many
checks need to be done - with my code, the only check done on each call
is whether or not the type has been initialized (and the JIT can cache
that information, or pre-initialize if it's marked as beforefieldinit ,
etc). With the double-check lock algorithm, you need to check whether
or not the static field is null every time, and the first time through
you need to take out a lock as well. You need to do those things *as
well* as all the checks that are in the faster version, because
obviously the type needs to still have been loaded/initialized (even if
initialization merely consists of making sure that there's no real
initialization to do).

I haven't got a handy benchmark on this ready to post, but I could
write one if you're interested.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Mountain Bikn' Guy <vc@attbi.com > wrote:

You mention the following:
"There are complications if one static constructor invokes another which
invokes the first again."

I have run into this problem (or a very similar one) quite frequently,
actually, using the first singleton pattern I posted. Specifically, I have seen cases where a threadsafe singleton created in a situation where the
static constructors which refer to each other in a cycle then seemingly
contains two different values in one field, depending upon whether that
field is accessed by the other singleton or some third object. Note that I witnessed this even thought I don't explicity use a static constructor in my singleton pattern.
I may not have been very precise here - I'll check later on. You don't
need to be using an explicit static constructor to get this kind of
behaviour, just static initialization of some description.

Thanks. That clarification helps.

Also, you mention "It still doesn't perform as well as the later
implementations " in regard to your 3rd example. However, I assume that
whenever you are mentioning performance on this page, you are referring only to laziness. (I ready your excellent discussion on your "beforefieldinn it" page, which led me to understand that laziness != better performance in all situations -- and that also led me to ask you to clarify that the word
performance on your singleton page refers strictly to laziness).

Nope, it's not to do with laziness (and as you've inferred, enforcing
strict laziness can reduce performance). It's to do with how many
checks need to be done.

Thanks again. I recognized the error of my statement -- but only after I had
already posted it. (Where's that "Unsend" button?)

Jon, I would really appreciate your clarification on whether the explicit
static ctor can be left out of both example 4 and example 5 of your
singleton patterns without impacting their thread safety.

Regards,
Mountain

Mountain Bikn' Guy <vc@attbi.com > wrote:

Jon, I would really appreciate your clarification on whether the explicit
static ctor can be left out of both example 4 and example 5 of your
singleton patterns without impacting their thread safety.

It definitely can. The static constructor itself is *only* necessary
for laziness.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Hi Lefty :)

Thanks again. I recognized the error of my statement -- but only after I had already posted it. (Where's that "Unsend" button?)

Actually there is one: Message/Cancel Message in our favorite newsreader OE.
Unfortunatelly it doesn't seem to work with ms newsgroups.

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Jon
Double locking pattern is not thread safe in .NET as well as in Java.
See Cris Brumme's blog and other places

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Mountain Bikn' Guy <vc@attbi.com > wrote:

You mention the following:
"There are complications if one static constructor invokes another which
invokes the first again."

I have run into this problem (or a very similar one) quite frequently,
actually, using the first singleton pattern I posted. Specifically, I have seen cases where a threadsafe singleton created in a situation where the
static constructors which refer to each other in a cycle then seemingly
contains two different values in one field, depending upon whether that
field is accessed by the other singleton or some third object. Note that I witnessed this even thought I don't explicity use a static constructor in my singleton pattern.

I may not have been very precise here - I'll check later on. You don't
need to be using an explicit static constructor to get this kind of
behaviour, just static initialization of some description.

Also, you mention "It still doesn't perform as well as the later
implementations " in regard to your 3rd example. However, I assume that
whenever you are mentioning performance on this page, you are referring only to laziness. (I ready your excellent discussion on your "beforefieldinn it" page, which led me to understand that laziness != better performance in all situations -- and that also led me to ask you to clarify that the word
performance on your singleton page refers strictly to laziness).

Nope, it's not to do with laziness (and as you've inferred, enforcing
strict laziness can reduce performance). It's to do with how many
checks need to be done - with my code, the only check done on each call
is whether or not the type has been initialized (and the JIT can cache
that information, or pre-initialize if it's marked as beforefieldinit ,
etc). With the double-check lock algorithm, you need to check whether
or not the static field is null every time, and the first time through
you need to take out a lock as well. You need to do those things *as
well* as all the checks that are in the faster version, because
obviously the type needs to still have been loaded/initialized (even if
initialization merely consists of making sure that there's no real
initialization to do).

I haven't got a handy benchmark on this ready to post, but I could
write one if you're interested.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Me <di******@yahoo .com> wrote:

Double locking pattern is not thread safe in .NET as well as in Java.

Indeed, that's my feeling too. That's why I've said so in the article -
or rather, I've said that although there are reports that it *is*
thread-safe in .NET, I can't see why it would be, and other people
report that it isn't. Perhaps it's time to word that even more strongly
though...

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too