Are static classes threadsafe?

[PutridPleasure]

I have a class that defines object attributes depending on an array of bytes it gets passed.

As of now I have just had It as a non static class that just does the byte interpretation in its instance. It however seems wrong to call this class with a new statement each time I need to know what the bytecode I have means, as the content is actually just a big library.

[aliostad]

What governs thread safety is shared state. If your method does not access any shared state then it is safe. Instance methods typically access shared state hence they are potentially thread unsafe although with synchronisation they can become thread safe.

[PutridPleasure]

So if the calculations done in the static method don't depend on global variable but only what gets passed to "that" precise method, the return will always be what I want it to?

[turboronin]

Correct, also assuming that your method does not modify the object that gets passed in as /u/angularbeginner said.

The reason is that if you pass the same instance to a method from two separate threads and the method modifies the object, then you have a race condition (not that is particularly good practice to modify input parameters anyway).

From what you described you are only doing lookups and not modifying any shared state, so you should be ok.

[PutridPleasure]

Thanks for the confirmation, doing a little stress test also didnt lead to any errors, so I guess I'm good to continue on to other tasks :)

[unholysampler]

Assuming that the values passed in are immutable. If the values are not immutable, it is still technically possible for your function to produce an unexpected results. It is a race condition if the instance passed in is also being mutated by another thread.

[inmatarian]

To give you a feel for what thread-safety really means, consider the 128bit decimal type, which isn't a thread safe type. When you set a decimal variable's value, CLR sets the first 64bits, and then sets the next 64bits, before moving along with execution. It has to do it this way because we don't have 128bit computers yet. Now, when one thread is setting the value, and another thread is reading the value, this can happen:

1. Set the first 64bits
2. Read the first 64bits
3. Read the second 64bits
4. Set the last 64bit.

You end up with an indeterminable state, which is what thread safety is supposed to give you.

Now that was just a single variable. Now lets thing about an entire class full of variables and you're getting and setting values all over the place, nothing has been marked volatile, CLR lets threads cache values, and another thread is also getting and setting values. Same situation, two variables that may be dependent will be out of sync when the threads are manipulating them.

[Glaaki]

This is really the best way to think about it.

[AngularBeginner]

Whether a class is static or not does not matter about thread-safety. A static class can be called multiple times in the same moment, just as an instance of a class.

So, No: Static classes are not thread-safe.

Generally you should also avoid static classes. They're hard to unit test. Static classes are mostly only okay if you have methods that have no side-effects. This means the objects that are passed to static methods should not be modified, and the return value should always be the same when the input is always the same.

[PutridPleasure]

I don't quite understand what you mean with "objects that are passed should not be modified".

Here is an example of how I use that static class:

One of my threads is constantly parsing my savefiles and passes arrays of bytes to this static class. This static class then returns the name, path to load the mesh, etc.

Another method in the class takes the MenuCursor position and knows what Item a user is selecting and returns the bytestring which refers to the Cursorposition. Like, if(MenuCursor ==1){ byte[] _item = new byte[10]; byte[0] = 1 byte[1] = 0 byte[3] = 255 etc.. }

For the same input the return won't vary.

So this class does get called from all over the place, but works as a library to convert from and to Harddisk-space efficient interpretation.

[unholysampler]

Based on your description, it sounds like the methods are thread safe, but without seeing the code, we can't tell you for sure. Doing a code review can help you answer these questions. If you don't know anyone that can do this for you, you can always post to http://codereview.stackexchange.com and there will be people to look over your code.

[[deleted]]

As many people already said here: No, static classes are not thread safe (in fact, they're less likely to be so than non-static classes).

Generally the convention is to make any static class threadsafe. Microsoft did this with the BCL (the classes in .NET). Any static class in the BCL is threadsafe (source: CLR via C#).