Thread-safety analyzer/simple guidelines

Warren,

AFAIK there is nothing like an analysis wizard for thread safety. FX
Cop might have some rules in it, but I don't know for sure (you can probably
google to see if there are rules for it, or custom rules that someone else
wrote that you agree with).

As for your points, the only one that is really off is #3. Local
variables are just that, local variables on the stack. They don't have
concerns about thread safety that member fields do, for example (since each
thread gets its own stack). However, you do have to be careful with what
local variables might reference. If you have a local variable that is
assigned an object reference which is shared, then you have to worry about
accessing that object, of course.

With #1 and #2, those are really just specializations of a more general
rule, that rule being that if the resource is shared among two threads, you
have to synchronize access to it.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Warren Sirota" <Wa**********@d iscussions.micr osoft.comwrote in message
news:87******** *************** ***********@mic rosoft.com...

Hi,

I've got a method that I want to execute in a multithreaded environment
(it's a specialized spider. I want to run a whole bunch of copies at low
priority as a service). It works well running as a single application.

I was wondering if there is a "Thread-Safety Analysis Wizard"?

I'm sure I'm grossly off-base with the following, so I'm prepared to be
embarrassed. Please point me in the right direction!

I would be tempted to summarize the thread-safety rules as the following:
1. Don't make unsynchronized calls to framework (and 3rd party) methods
that
are known to not be thread-safe (and how do I find out which are which, I
wonder?)
2. Don't make unsynchronized changes to static fields (I'm not sure
whether
unsynchronized reads would be considered safe or not).
3. Similar to #2, watch out for access to local variables in static
methods.

So, am I far off? Am I missing about 100 other cases, or some big
principles
here?

Thanks for your advice.

--
Warren Sirota
www.wsdesigns.com

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard .caspershouse.c omwrote:

AFAIK there is nothing like an analysis wizard for thread safety. FX
Cop might have some rules in it, but I don't know for sure (you can probably
google to see if there are rules for it, or custom rules that someone else
wrote that you agree with).

As for your points, the only one that is really off is #3. Local
variables are just that, local variables on the stack. They don't have
concerns about thread safety that member fields do, for example (since each
thread gets its own stack). However, you do have to be careful with what
local variables might reference. If you have a local variable that is
assigned an object reference which is shared, then you have to worry about
accessing that object, of course.

These days, I worry about even local variables. The way I read the blog
entry at
http://blogs.msdn.com/grantri/archiv...07/226355.aspx
even the following code is unsafe:
void Foo()
{
string x = someMemberVaria ble;

if (x != null)
{
Console.WriteLi ne (x.Length);
}
}

That looks like it can't throw a NullReferenceEx ception, right?
According to the blog article, the IA-64 JIT may notice that x is only
ever an alias for someMemberVaria ble, and not bother with the local
variable at all. I find that intensely worrying...

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

Warren,

Warren Sirota wrote:

Hi,

I've got a method that I want to execute in a multithreaded environment
(it's a specialized spider. I want to run a whole bunch of copies at low
priority as a service). It works well running as a single application.

I was wondering if there is a "Thread-Safety Analysis Wizard"?

I'm sure I'm grossly off-base with the following, so I'm prepared to be
embarrassed. Please point me in the right direction!

I would be tempted to summarize the thread-safety rules as the following:
1. Don't make unsynchronized calls to framework (and 3rd party) methods that
are known to not be thread-safe (and how do I find out which are which, I
wonder?)

The documentation for every class in the BCL has a thread-safety
section. All classes guarentee thread-safe implementations for static
members (I say all because I haven't seen any that don't) and only a
few guarentee it for instance members. Third party libraries should
contain similar documentation.

2. Don't make unsynchronized changes to static fields (I'm not sure whether
unsynchronized reads would be considered safe or not).

That's pretty much correct. One exception is events. According to the
specification the default add and remove accessors for an event are
thread-safe. Now, I realize the accessors aren't actually fields, but
since the compiler creates default accessors it may be confusing.
Reads can be very confusing. I *think* a read of a readonly static
field or a field that was initialized in the static constructor should
be fine, but aside from that one thread could change the field and
another wouldn't see the change because of compiler or hardware
optimizations.

3. Similar to #2, watch out for access to local variables in static methods.

Nick already explained this.

So, am I far off? Am I missing about 100 other cases, or some big principles
here?

Well, the specification should spell out all of the
rules...theorec tically anyway. The problem is that they may not all be
in one place so you'd have poke around and then you'd have to interpret
and apply them correctly to each case.

>
Thanks for your advice.

--
Warren Sirota
www.wsdesigns.com

Jon wrote:

These days, I worry about even local variables. The way I read the blog
entry at
http://blogs.msdn.com/grantri/archiv...07/226355.aspx
even the following code is unsafe:
void Foo()
{
string x = someMemberVaria ble;

if (x != null)
{
Console.WriteLi ne (x.Length);
}
}

That looks like it can't throw a NullReferenceEx ception, right?
According to the blog article, the IA-64 JIT may notice that x is only
ever an alias for someMemberVaria ble, and not bother with the local
variable at all. I find that intensely worrying...

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

Holy incomprehensibl e memory model batman. That's why low-lock
techniques are insanely difficult to get right.