Only static (Shared) types are thread safe ?!

OleDbCommand class like many .NET classes has the following description in
its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their own
stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

OleDbCommand class like many .NET classes has the following description in
its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their own
stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

There is overhead in making a method thread safe. Microsoft typically
will not add the overhead to an instance (non static) method, because
90% of the time the overhead will be unneeded. This leaves it up to
the developer to add thread safety only when they need it.

Microsoft will typically make static methods threadsafe, because there
is a good chance the Type will be used in an MT environment.

I have a couple articles on the topic, let me know if they help or if
they can be improved:
Statics And Thread Safety (Parts I and II)
http://odetocode.com/Articles/313.aspx
http://odetocode.com/Articles/314.aspx

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Wed, 31 Aug 2005 08:55:09 -0400, "dee" <de*@home.net> wrote:

OleDbCommand class like many .NET classes has the following description in
its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe
for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their
own
stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is
that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

dee wrote:

OleDbCommand class like many .NET classes has the following description
in
its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe
for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their
own
stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is
that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

I think this is a language problem here. I believe the phrase:

"Any public static (Shared in Visual Basic) members of this type are
safe for multithreaded operations"

is meant to be read

"Any public static (Shared in Visual Basic) memebers that this type
exposes are safe for multithreaded operations"

rather than

"Any public static (Shared in Visual Basic) members defined to be of
this type are safe for multithreaded operations"

It's quite ambiguous phrasing, but I believe that what I have stated
(the second quote) is the intended meaning.

Does this clear things up?

Damien

Yes Damian Thanks.
In addition, why would an intrinsic method be unsafe? cuz it might access
static data? Then why not thread safe those as well?
"Damien" <Da*******************@hotmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...

dee wrote:

OleDbCommand class like many .NET classes has the following description
in
its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe
for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their
own
stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is
that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

I think this is a language problem here. I believe the phrase:

"Any public static (Shared in Visual Basic) members of this type are
safe for multithreaded operations"

is meant to be read

"Any public static (Shared in Visual Basic) memebers that this type
exposes are safe for multithreaded operations"

rather than

"Any public static (Shared in Visual Basic) members defined to be of
this type are safe for multithreaded operations"

It's quite ambiguous phrasing, but I believe that what I have stated
(the second quote) is the intended meaning.

Does this clear things up?

Damien

OleDbCommand class like many .NET classes has the following description in
its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe
for multithreaded operations. Any instance members are not guaranteed to
be thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their
own stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is
that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

when the docs refer to members thread safety, they are refering to
accessing that property from different threads.

when they say statics are thread safe, but instance are not, they mean,
that the static can be access from any thread safefully (as locking as
been implementd), but instance members can only be safely accessed from
the creating thread.

if an non-thread safe instance member is to be accessed from multiple
threads, you must add code to support this.

-- bruce (sqlwork.com)
"dee" <de*@home.net> wrote in message
news:uH**************@TK2MSFTNGP15.phx.gbl...

OleDbCommand class like many .NET classes has the following description
in its help file:

"Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe
for multithreaded operations. Any instance members are not guaranteed to
be thread safe."
I have 2 questions:

1. I thought dynamic variables are thread-safe since threads have their
own stack and static data had to be synchronized. However, many many .NET
classes say ONLY static members of thier type are thread safe. Why is
that?
2. Do we still have to synchronize access to this shared data?

3. If only static members are thread-safe why all the examples use non
static data?

Thanks.
Dee

OleDbCommand class doesnt have any static members anyway
what is the point of mentioning static members are thread safe ??

When they day "member" then mean either a method or a property?
"instance member" could be a method that uses a static proptery? If so, then
they should be handled like other static methods since thier user does
doesnt know how they are implemented.

Thanks for your time.
Dee

dee wrote:

OleDbCommand class doesnt have any static members anyway
what is the point of mentioning static members are thread safe ??

It's just a boilerplate statement that they've liberally sprinkled
throughout the documentation. I wouldn't try to read too much into it.

In the general case (when you're not passing instances around between
threads), it's only the static members that you would be concerned
about w.r.t thread safety, since those are the only ones which multiple
threads might conceivably call (on the same object, in this case the
type). Once you start passing instances between threads is when you
start having to think about implementing mutual exclusion (unless the
documentation, in that case, states that all members are thread safe).

HTH,

Damien

On Wed, 31 Aug 2005 11:10:15 -0400, "dee" <de*@home.net> wrote:

When they day "member" then mean either a method or a property?
"instance member" could be a method that uses a static proptery? If so,
then
they should be handled like other static methods since thier user does
doesnt know how they are implemented.

Thanks for your time.
Dee

Yes, members would include both properties and methods.

--
Scott
http://www.OdeToCode.com/blogs/scott/