[ACCEPTED]-How do I know if this C# method is thread safe?-static-methods

That addOne function is indeed thread safe because 6 it doesn't access any data that could be 5 accessed by another thread. Local variables 4 cannot be shared among threads because each 3 thread gets its own stack. You do have to 2 make sure, however, that the function parameters 1 are value types and not reference types.

static void MyFunction(int x) { ... } // thread safe. The int is copied onto the local stack.

static void MyFunction(Object o) { ... } // Not thread safe. Since o is a reference type, it might be shared among multiple threads. 

No, addOne is thread-safe here - it only 12 uses local variables. Here's an example 11 which wouldn't be thread-safe:

 class BadCounter
 {
       private static int counter;

       public static int Increment()
       {
             int temp = counter;
             temp++;
             counter = temp;
             return counter;
       }
 }

Here, two threads 10 could both call Increment at the same time, and 9 end up only incrementing once. (Using return ++counter; would 8 be just as bad, by the way - the above is 7 a more explicit version of the same thing. I 6 expanded it so it would be more obviously 5 wrong.)

The details of what is and isn't 4 thread-safe can be quite tricky, but in 3 general if you're not mutating any state 2 (other than what was passed into you, anyway 1 - bit of a grey area there) then it's usually okay.

Threading issues (which I've also been worrying 148 about lately) arise from the use of multiple 147 processor cores with separate caches, as 146 well as from basic thread-swapping race 145 conditions. If the caches for separate 144 cores access the same memory location, they 143 will generally have no idea about the other 142 one and may separately track the state of 141 that data location without it going back 140 out to main memory (or even to a synchronized 139 cache shared across all cores at L2 or L3, for 138 example), for processor performance reasons. So 137 even order-of-execution interlock tricks 136 may not be reliable in multi-threaded environments.

As 135 you may know, the main tool to correct for 134 this is a lock, which provides a mechanism 133 for exclusive access (between contentions 132 for the same lock) and handles the underlying 131 cache synchronization so that accesses to 130 the same memory location by various lock-protected 129 code sections will be properly serialized. You 128 can still have race conditions between who 127 gets the lock when and in what order, but 126 that's usually much simpler to deal with 125 when you can guarantee that execution of 124 a locked section is atomic (within the context 123 of that lock).

You can get a lock on an instance 122 of any reference type (eg. inherits from 121 Object, not value types like int or enums, and 120 not null), but it's very important to understand 119 that the lock on an object has no inherent 118 effect on accesses to that object, it only 117 interacts with other attempts to get the 116 lock on the same object. It is up to the 115 class to protect access to its member variables 114 using an appropriate locking scheme. Sometimes 113 instances might protect multi-threaded accesses 112 to their own members by locking on themselves 111 (eg. lock (this) { ... } ), but usually this is not necessary 110 because instances tend to be held by only 109 one owner and don't need to guarantee threadsafe 108 access to the instance.

More commonly, a 107 class creates a private lock (eg. private readonly object m_Lock = new Object(); for separate 106 locks within each instance to protect access 105 to members of that instance, or private static readonly object s_Lock = new Object(); for a central 104 lock to protect access to the class's static 103 members). Josh has a more specific code 102 example of using a lock. You then have 101 to code the class to use the lock appropriately. In 100 more complex cases you might even want to 99 create separate locks for different groups 98 of members, to reduce contention for different 97 kinds of resources which aren't used together.

So, to 96 bring it back to your original question, a 95 method which only accesses its own local 94 variables and parameters would be thread-safe, because 93 these exist in their own memory locations 92 on the stack specific to the current thread, and 91 can not be accessed elsewhere--unless you 90 shared those parameter instances across 89 threads before passing them.

A non-static 88 method which only accesses the instances 87 own members (no static members)--and of 86 course parameters and local variables--would 85 not need to use locks in the context of 84 that instance being used by a single owner 83 (doesn't need to be thread-safe), but if 82 instances were intended to be shared and 81 wanted to guarantee thread-safe access, then 80 the instance would need to protect access 79 to its member variables with one or more 78 locks specific to that instance (locking 77 on the instance itself being one option)--as 76 opposed to leaving it up to the caller to 75 implement their own locks around it when 74 sharing something not intended to be thread-safe 73 shareable.

Access to readonly members (static 72 or non-static) which aren't ever manipulated 71 is generally safe, but if the instance it 70 holds is not itself thread-safe or if you 69 need to guarantee atomicity across multiple 68 manipulations of it, then you may need to 67 protect all access to it with your own locking 66 scheme as well. That's a case where it 65 could be handy if the instance uses locking 64 on itself, because you could simply get 63 a lock on the instance across multiple accesses 62 into it for atomicity, but you wouldn't 61 need to do so for single accesses into it 60 if it's using a lock on itself to make those 59 accesses individually thread-safe. (If 58 it's not your class, you'd have to know 57 whether it locks on itself or is using a 56 private lock which you can't access externally.)

And 55 finally, there's access to changing static 54 members (changed by the given method or 53 by any others) from within an instance--and 52 of course static methods which access those 51 static members and could be called from 50 anyone, anywhere, anytime--which have the 49 biggest need to use responsible locking, without 48 which are definitely not thread-safe and 47 are likely to cause unpredictable bugs.

When 46 dealing with .NET framework classes, Microsoft 45 documents in MSDN whether a given API call 44 is thread-safe (eg. static methods of the 43 provided generic collection types like List<T> are 42 made thread-safe while instance methods 41 may not be--but check specifically to be 40 sure). The vast majority of the time (and 39 unless it specifically says it's thread-safe), it's 38 not internally thread-safe, so it's your 37 responsibility to use it in a safe manner. And 36 even when individual operations are implemented 35 internally thread-safe, you still have to 34 worry about shared and overlapping access 33 by your code if it does anything more complex 32 which needs to be atomic.

One big caveat 31 is iterating over a collection (eg. with 30 foreach). Even if each access to the collection 29 gets a stable state there's no inherent 28 guarantee that it won't change in between 27 those accesses (if anywhere else can get 26 to it). When the collection is held locally 25 there's generally no problem, but a collection 24 which could be changed (by another thread 23 or during your loop's execution!) could 22 produce inconsistent results. One easy 21 way to solve this is to use an atomic thread-safe 20 operation (inside your protective locking 19 scheme) to make a temporary copy of the 18 collection (MyType[] mySnapshot = myCollection.ToArray();) and then iterate over that 17 local snapshot copy outside the lock. In 16 many cases this avoids the need for holding 15 a lock the whole time, but depending on 14 what you're doing within the iteration this 13 may not be enough and you just have to protect 12 against changes the whole time (or you may 11 already have it inside a locked section 10 guarding against access to change the collection 9 along with other things, so it's covered).

So, there's 8 a bit of an art to thread-safe design, and 7 knowing just where and how to get locks 6 to protect things depends a lot on the overall 5 design and usage of your class(es). It 4 can be easy to get paranoid and think you 3 have to get locks all over for everything, but 2 really it's about finding the right layer 1 at which to protect things.

Your method is fine since it is only using 7 local variables, let's change your method 6 a bit:

static int foo;

static int addOne(int someNumber)
{
  foo=someNumber; 
  return foo++;
}

This is not a thread safe method because 5 we are touching static data. This would 4 then need to be modified to be:

static int foo;
static object addOneLocker=new object();
static int addOne(int someNumber)
{
  int myCalc;
  lock(addOneLocker)
  {
     foo=someNumber; 
     myCalc= foo++;
  }
  return myCalc;
}

Which I think 3 this is a silly sample I just did cause 2 if I'm reading it correctly there is no 1 point in foo anymore but hey it's a sample.

There is some research going on which allows 2 you to detect non-thread-safe code. E.g. the 1 project CHESS at Microsoft Research.

This would only be a race condition if it 19 were modifying some variable external to 18 the function. Your example is not doing 17 that.

That's basically what you're looking 16 out for. Thread safe means that the function 15 either:

1. Does not modify external data, or
2. Access to external data is properly synchronized so that only one function can access it at any one time.

External data could be something 14 held in storage (database/file), or something 13 internal to the application (a variable, an 12 instance of a class, etc): basically anything 11 that is declared anywhere in the world that 10 is outside of the function's scope.

A trivial 9 example of an un-thread safe version of 8 your function would be this:

private int myVar = 0;

private void addOne(int someNumber)
{
   myVar += someNumber;
}

If you call 7 this from two different threads without 6 synchronization, querying the value of myVar 5 will be different depending on whether the 4 query happens after all calls to addOne 3 are complete, or the query happens in between 2 the two calls, or the query happens before 1 either of the calls.

In the above example no.

Thread safety is 11 mainly to do with stored state. You can 10 make the above example non thread safe by 9 doing this:

static int myInt;

static int addOne(int someNumber){
myInt = someNumber;
return myInt +1; 
}

This will mean that due to context 8 switching thread 1 might get to the call 7 myInt = someNumber and then context switch, lets 6 say thread 1 just set it to 5. Then imagine 5 that thread 2 comes in and uses 6 and returns 4 7. Then when thread 1 wakes up again it 3 will have 6 in myInt instead of the 5 that 2 it was using and return 7 instead of the 1 expected 6. :O

Anywhere, thread safe means that you don't have two 10 or more threads colliding when you are accessing 9 a resource. Usually static varaiables --- in 8 languages like C#, VB.NET and Java --- made 7 your code thread unsafe.

In Java exists the synchronized keyword. But 6 in .NET you get the assembly option/directive:

class Foo
{
    [MethodImpl(MethodImplOptions.Synchronized)]
    public void Bar(object obj)
    {
        // do something...
    }
}

Examples 5 of non thread safe classes should be singletons, depending 4 on how is this pattern coded. Usually it 3 must implement a synchronized instance creator.

If you 2 don't want a synchronized method, you can try locking method, such 1 as spin-lock.

any access to an obect that can be used 6 simultaneously by two threads is not threadsafe.

your 5 example in Part 2 is clearly safe, as it 4 uses only values passed in as arguments, but 3 if you used an object scoped variable you 2 might have to surround the access with appropriate 1 lock statements

foo is not shared between concurrent or sequential 1 invocations, so addOne is thread-safe.

The reason that 'foo' and 'someNumber' are 7 safe in your example is that they reside 6 on the stack, and each thread has their 5 own stack and so are not shared.

As soon 4 as data has the potential to be shared, for 3 example, being global or sharing pointers 2 to objects, then you could have conflicts 1 and may need to use locks of some sort.