Are All the Static/Shared Methods in .NET Thread Safe?

The declaration is usually described as 'Any public static (Shared in
Visual Basic) members of this type are thread safe. Any instance members are
not guaranteed to be thread safe.'
So, does this mean All the static/shared methods written in .NET compatible
programming language, such as C#, VB.NET, are guaranteed to be synchronized
and thread safe?

Yes. I have never heard of a static (Shared) method *not* being
thread-safe.

The reason that static / Shared methods are always thread-safe is because
there is no instance of a class, and therefore, no member variables for
threads to stomp on in contradictory ways.

Any local variables inside a static / Shared method exist locally within the
particular stack frame of the calling code on the calling thread, and
therefore, will never conflict with multiple threads simultaneously hitting
the same method with local variables.
--

Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

Not necessarily true. If the static/shared method contains internal state
variables that it maintains across calls, it may not be thread safe if the
implementer didn't ensure internal thread safety. That said, I don't
believe there are any non-thread safe static/shared methods in the framework
itself, but given the size of the framework, I don't think you can guarantee
that any given method is thread safe without referring to the documentation.

Mike Ober.

"Mike Labosh" <mlabosh_at_hotmail_dot_comwrote in message
news:eD**************@TK2MSFTNGP06.phx.gbl...

>The declaration is usually described as 'Any public static (Shared in

Visual Basic) members of this type are thread safe. Any instance members
are
not guaranteed to be thread safe.'
So, does this mean All the static/shared methods written in .NET
compatible
programming language, such as C#, VB.NET, are guaranteed to be
synchronized
and thread safe?

Yes. I have never heard of a static (Shared) method *not* being
thread-safe.

The reason that static / Shared methods are always thread-safe is because
there is no instance of a class, and therefore, no member variables for
threads to stomp on in contradictory ways.

Any local variables inside a static / Shared method exist locally within
the
particular stack frame of the calling code on the calling thread, and
therefore, will never conflict with multiple threads simultaneously
hitting
the same method with local variables.
--

Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

"Mike Labosh" <mlabosh_at_hotmail_dot_comwrote in message
news:eD**************@TK2MSFTNGP06.phx.gbl...

>The declaration is usually described as 'Any public static (Shared in

Visual Basic) members of this type are thread safe. Any instance members
are
not guaranteed to be thread safe.'
So, does this mean All the static/shared methods written in .NET
compatible
programming language, such as C#, VB.NET, are guaranteed to be
synchronized
and thread safe?

Yes. I have never heard of a static (Shared) method *not* being
thread-safe.

The reason that static / Shared methods are always thread-safe is because
there is no instance of a class, and therefore, no member variables for

Not necessarily true. See Array.Resize for instance, which needs a class
instance.

threads to stomp on in contradictory ways.

Any local variables inside a static / Shared method exist locally within
the
particular stack frame of the calling code on the calling thread, and
therefore, will never conflict with multiple threads simultaneously
hitting
the same method with local variables.

And what about static member variables?

--

Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

On Mar 20, 8:03 am, "Mike Labosh" <mlabosh_at_hotmail_dot_comwrote:

The reason that static / Shared methods are always thread-safe is because
there is no instance of a class, and therefore, no member variables for
threads to stomp on in contradictory ways.

But there could be static fields. Those would have to be synchronized
just like instance fields. The reason why Microsoft chose to make
most static properties and methods thread-safe is because they're
commonly used across many threads and it would incovenient for the
callers to figure out how to synchronize them on their own. Imagine
what it would look like if Console.WriteLine had to be wrapped with a
lock everytime. That's just plain nasty.

On Mar 20, 1:03 pm, "Mike Labosh" <mlabosh_at_hotmail_dot_comwrote:

The reason that static / Shared methods are always thread-safe is because
there is no instance of a class, and therefore, no member variables for
threads to stomp on in contradictory ways.

And what about static variables?

Any local variables inside a static / Shared method exist locally within the
particular stack frame of the calling code on the calling thread, and
therefore, will never conflict with multiple threads simultaneously hitting
the same method with local variables.

With reference types, two different threads could still be accessing
the same *objects*, even though the local variables themselves are
independent.

Basically, whenever there's shared data, there can be threading
issues. There's nothing to stop static methods sharing data with other
executing code, therefore there can be threading issues.

Jon

Any method (static or otherwise) that is called by multiple threads and uses
any shared state must be aware of syncronization and take require action
depending on needs. Static != thread safe.

--
William Stacey [C# MVP]
"Mike Labosh" <mlabosh_at_hotmail_dot_comwrote in message
news:eD**************@TK2MSFTNGP06.phx.gbl...
|The declaration is usually described as 'Any public static (Shared in
| Visual Basic) members of this type are thread safe. Any instance members
are
| not guaranteed to be thread safe.'
| So, does this mean All the static/shared methods written in .NET
compatible
| programming language, such as C#, VB.NET, are guaranteed to be
synchronized
| and thread safe?
|
| Yes. I have never heard of a static (Shared) method *not* being
| thread-safe.
|
| The reason that static / Shared methods are always thread-safe is because
| there is no instance of a class, and therefore, no member variables for
| threads to stomp on in contradictory ways.
|
| Any local variables inside a static / Shared method exist locally within
the
| particular stack frame of the calling code on the calling thread, and
| therefore, will never conflict with multiple threads simultaneously
hitting
| the same method with local variables.
| --
|
| Peace & happy computing,
|
| Mike Labosh, MCSD MCT
| Owner, vbSensei.Com
|
| "Escriba coda ergo sum." -- vbSensei
|
|

"Laser Lu" <la******@163.comschrieb:

>The declaration is usually described as 'Any
public static (Shared in Visual Basic) members
of this type are thread safe. Any instance
members are not guaranteed to be thread safe.'
So, does this mean All the static/shared
methods written in .NET compatible programming
language, such as C#, VB.NET, are guaranteed
to be synchronized and thread safe?

No.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Here's the deal... the only difference (that I am aware of) between
static and instance methods is that instance methods pass the "this"
pointer silently while static methods do not; that's it. I think that
the reason why static methods have been marked as "thread safe" is
that they are assuming that, since the method is static, you won't be
accessing any shared-state as you most likely would in an instance
method. Both instance methods and static methods *are* thread-safe as
long as you don't access any shared-state (eg. instance/static fields)
since each thread has its own local stack.

In short, if you have a multi-threaded application that needs to
access shared-state, you need to synchronize all access via a locking
mechanism such as lock, mutexes, monitor, etc...

Here's a link that might help : http://www.odetocode.com/Articles/313.aspx

Regards,

Anthony

On Mar 20, 4:08 am, "Laser Lu" <laser...@163.comwrote:

I was often noted by Thread Safety declarations when I was reading .NET Framework Class Library documents in MSDN.
The declaration is usually described as 'Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.'
So, does this mean All the static/shared methods written in .NET compatible programming language, such as C#, VB.NET, are guaranteed to be synchronized and thread safe? Or else, we still need to implement our custom code to ensure the thread-safty for static methods?

Thanks!

"William Stacey [C# MVP]" <wi************@gmail.comwrote in message
news:Op**************@TK2MSFTNGP03.phx.gbl...

Any method (static or otherwise) that is called by multiple threads and
uses
any shared state must be aware of syncronization and take require action
depending on needs. Static != thread safe.

--
William Stacey [C# MVP]
"Mike Labosh" <mlabosh_at_hotmail_dot_comwrote in message
news:eD**************@TK2MSFTNGP06.phx.gbl...
|The declaration is usually described as 'Any public static (Shared in
| Visual Basic) members of this type are thread safe. Any instance members
are
| not guaranteed to be thread safe.'
| So, does this mean All the static/shared methods written in .NET
compatible
| programming language, such as C#, VB.NET, are guaranteed to be
synchronized
| and thread safe?
|
| Yes. I have never heard of a static (Shared) method *not* being
| thread-safe.
|
| The reason that static / Shared methods are always thread-safe is
because
| there is no instance of a class, and therefore, no member variables for
| threads to stomp on in contradictory ways.
|
| Any local variables inside a static / Shared method exist locally within
the
| particular stack frame of the calling code on the calling thread, and
| therefore, will never conflict with multiple threads simultaneously
hitting
| the same method with local variables.
| --
|
| Peace & happy computing,
|
| Mike Labosh, MCSD MCT
| Owner, vbSensei.Com
|
| "Escriba coda ergo sum." -- vbSensei
|
|

Thanks for your reply. Now, I've had a better understanding based on your
explaination.:)

"Anthony Paul" <an**********@gmail.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...

Here's the deal... the only difference (that I am aware of) between
static and instance methods is that instance methods pass the "this"
pointer silently while static methods do not; that's it. I think that
the reason why static methods have been marked as "thread safe" is
that they are assuming that, since the method is static, you won't be
accessing any shared-state as you most likely would in an instance
method. Both instance methods and static methods *are* thread-safe as
long as you don't access any shared-state (eg. instance/static fields)
since each thread has its own local stack.

In short, if you have a multi-threaded application that needs to
access shared-state, you need to synchronize all access via a locking
mechanism such as lock, mutexes, monitor, etc...

Here's a link that might help : http://www.odetocode.com/Articles/313.aspx

Regards,

Anthony

On Mar 20, 4:08 am, "Laser Lu" <laser...@163.comwrote:

>I was often noted by Thread Safety declarations when I was reading .NET
Framework Class Library documents in MSDN.
The declaration is usually described as 'Any public static (Shared in
Visual Basic) members of this type are thread safe. Any instance members
are not guaranteed to be thread safe.'
So, does this mean All the static/shared methods written in .NET
compatible programming language, such as C#, VB.NET, are guaranteed to be
synchronized and thread safe? Or else, we still need to implement our
custom code to ensure the thread-safty for static methods?

In my idea to the best answer

A-ha, quite agree with u. The most brief and definite answer.:)

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eW****************@TK2MSFTNGP03.phx.gbl...

In my idea to the best answer

They are marked thread-safe, only when the *author (in this case MS) has
taken the time to verify they are thread safe (which is easy if they don't
touch shared data). As most statics in the framework (not sure if all are)
are documented with the thread safe attribute, it is easy to assume that is
some kind of special gaureentee all statics give - which is not the case.
You can easily make a non thread safe static method via bug or on purpose.

--
William Stacey [C# MVP]
"Anthony Paul" <an**********@gmail.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
| Here's the deal... the only difference (that I am aware of) between
| static and instance methods is that instance methods pass the "this"
| pointer silently while static methods do not; that's it. I think that
| the reason why static methods have been marked as "thread safe" is
| that they are assuming that, since the method is static, you won't be
| accessing any shared-state as you most likely would in an instance
| method. Both instance methods and static methods *are* thread-safe as
| long as you don't access any shared-state (eg. instance/static fields)
| since each thread has its own local stack.
|
| In short, if you have a multi-threaded application that needs to
| access shared-state, you need to synchronize all access via a locking
| mechanism such as lock, mutexes, monitor, etc...
|
| Here's a link that might help : http://www.odetocode.com/Articles/313.aspx
|
| Regards,
|
| Anthony
|
| On Mar 20, 4:08 am, "Laser Lu" <laser...@163.comwrote:
| I was often noted by Thread Safety declarations when I was reading .NET
Framework Class Library documents in MSDN.
| The declaration is usually described as 'Any public static (Shared in
Visual Basic) members of this type are thread safe. Any instance members are
not guaranteed to be thread safe.'
| So, does this mean All the static/shared methods written in .NET
compatible programming language, such as C#, VB.NET, are guaranteed to be
synchronized and thread safe? Or else, we still need to implement our custom
code to ensure the thread-safty for static methods?
|
|