Only static (Shared) types are thread safe ?!

[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

 

[Scott Allen]

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

 

[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

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

 

[dee]

Thanks Scott nice articles.
I guess my problem is with the meaning of the line from help file:
"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."

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]

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?

 

[dee]

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

 

[Bruce Barker]

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]

Thanks Bruce

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)

 

[Damien]

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

 

[Scott Allen]

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.

 

[dee]

Thanks Damien

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

 

[dee]

Thanks Allen.

Yes, members would include both properties and methods.