469,275 Members | 1,552 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,275 developers. It's quick & easy.

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

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?
Mar 20 '07 #1
15 2464
"Laser Lu" <la******@163.comwrote in message
news:OO**************@TK2MSFTNGP02.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? Or else, we still need to implement our custom
code to ensure the thread-safty for static methods?
The programming guidelines from Microsoft recommend that you make all
your public static methods thread-safe, and indeed they have followed those
guidelines in the classes that they have provided with the Framework.
However, this is not automatic. Just marking a method as static does not
guarantee that it will be tread-safe. you still have to examine your code
and see if there is something in it that could be affected, such as a shared
variable that could be accessed by two threads, and apply adequate locking
mechanisms to ensure its safety.

Mar 20 '07 #2
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
Mar 20 '07 #3
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


Mar 20 '07 #4

"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


Mar 20 '07 #5
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.

Mar 20 '07 #6
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

Mar 20 '07 #7
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
|
|
Mar 20 '07 #8
"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/>
Mar 20 '07 #9
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?

Mar 20 '07 #10
Ok, tank you.:)

"Alberto Poblacion" <ea******************************@poblacion.orgwro te
in message news:ey*************@TK2MSFTNGP02.phx.gbl...
"Laser Lu" <la******@163.comwrote in message
news:OO**************@TK2MSFTNGP02.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? Or else, we still need to implement our custom
code to ensure the thread-safty for static methods?

The programming guidelines from Microsoft recommend that you make all
your public static methods thread-safe, and indeed they have followed
those guidelines in the classes that they have provided with the
Framework.
However, this is not automatic. Just marking a method as static does
not guarantee that it will be tread-safe. you still have to examine your
code and see if there is something in it that could be affected, such as a
shared variable that could be accessed by two threads, and apply adequate
locking mechanisms to ensure its safety.

Mar 21 '07 #11
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
|
|


Mar 21 '07 #12
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?


Mar 21 '07 #13
In my idea to the best answer
Mar 21 '07 #14
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


Mar 21 '07 #15
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?
|
|
Mar 21 '07 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Steve | last post: by
2 posts views Thread by blue | last post: by
4 posts views Thread by Joe Fallon | last post: by
4 posts views Thread by =?iso-8859-1?B?Sm9oYW4gU2r2c3Ry9m0=?= | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.