C# 4.0: Are there ready-made, thread-safe autoimplemented properties?

Question

I would like to have thread-safe read and write access to an auto-implemented property. I am missing this functionality from the C#/.NET framework, even in it's latest version. At best, I would expect something like

[Threadsafe]
public int? MyProperty { get; set; }

I am aware that there are various code examples to achieve this, but I just wanted to be sure that this is still not possible using .NET framework methods only, before implementing something myself. Am I wrong?

EDIT: As some answers elaborate on atomicity, I want to state that I just want to have that, as far as I understand it: As long as (and not longer than) one thread is reading the value of the property, no other thread is allowed to change the value. So, multi-threading would not introduce invalid values. I chose the int? type because that is the on I am currently concerned about.

EDIT2: I have found the specific answer to the example with Nullable here, by Eric Lippert

Answer 1

Correct; there is no such device. Presumably you are trying to protect against reading the field while another thread has changed half of it (atomicity)? Note that many (small) primitives are inherently safe from this type of threading issue:

5.5 Atomicity of variable references

Reads and writes of the following data types are atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. In addition, reads and writes of enum types with an underlying type in the previous list are also atomic.

But in all honesty this is just the tip of the threading ice-berg; by itself it usually isn't enough to just have a thread-safe property; most times the scope of a synchronized block must be more than just one read/write.

There are also so many different ways of making something thread-safe, depending on the access profile;

• lock ?
• ReaderWriterLockSlim ?
• reference-swapping to some class (essentially a Box<T>, so a Box<int?> in this case)
• Interlocked (in all the guises)
• volatile (in some scenarios; it isn't a magic wand...)
• etc

(not to mention making it immutable (either through code, or by just choosing not to mutate it, which is often the simplest way of making it thread-safe)

Answer 2

I'm answering here to add to Marc's answer, where he says "there are also so many different ways of making something thread-safe, depending on the access profile".

I just want to add, that part of the reason for this, is that there are so many ways of not being thread-safe, that when we say something is thread-safe, we have to be clear on just what safety is provided.

With almost any mutable object, there will be ways to deal with it that are not thread-safe (note almost any, an exception is coming up). Consider a thread-safe queue that has the following (thread-safe) members; an enqueue operation, a dequeue operation and a count property. It's relatively easy to construct one of these either through locking internally on each member, or even with lock-free techniques.

However, say we used the object like so:

if(queue.Count != 0)
    return queue.Dequeue();

The above code is not thread-safe, because there is no guarantee that after the (thread-safe) Count returning 1, another thread won't dequeue and hence cause the second operation to fail.

It is still a thread-safe object in many ways, particularly as even in this case of failure, the failing dequeue operation will not put the object into an invalid state.

To make an object as a whole thread-safe in the face of any given combination of operations we have to either make it logically immutable (it's possible to have internal mutability with thread-safe operations updating internal state as an optimisation - e.g. through memoisation or loading from a datasource as needed, but to the outside it must appear immutable) or to severely reduce the number of external operations possible (we could create a thread-safe queue that only had Enqueue and TryDequeue which is always thread-safe but that both reduces the operations possible, and also forces a failed dequeue to be redefined as not being a failure, and forces a change in logic on calling code from the version we had earlier).

Anything else is a partial guarantee. We get some partial guarantees for free (as Marc notes, acting on some automatic properties are already thread-safe in regards to being individually atomic - which in some cases is all the thread safety we need, but in other cases doesn't go anywhere near far enough).

Let's consider an attribute that adds this partial guarantee to those cases where we don't already get it. Just how much value is it to us? Well, in some cases it will be perfect, but in others it won't. Going back to our case of testing before dequeue, having such a guarantee on Count isn't much use - we had that guarantee and the code still failed in multi-threaded conditions in a way it wouldn't in single-threaded conditions.

What's more, adding this guarantee to the cases that don't already have it requires at least a degree of overhead. It may be premature optimisation to worry about overhead all the time, but adding overhead for no gain is premature pessimisation, so lets not do that! What's more, if we do provide the wider concurrency control to make a set of operations truly thread-safe, then we will have rendered the narrower concurrency controls irrelevant, and they become pure overhead - so we don't even get value out of our overhead in some cases; it's almost always purely waste.

It's also not clear how wide or narrow the concurrency concerns are. Do we need to lock (or similar) only on that property, or do we need to lock on all properties? Do we need to lock also on non-automatic operations, and is that even possible?

There is no good single answer here (they can be tricky questions to answer in rolling your own solution, never mind in trying to answer it in the code that would produce such code when someone else has used this [Threadsafe] attribute).

Also, any given approach will have a different set of conditions in which deadlock, livelock, and similar problems can occur, so we can actually reduce thread-safety by treating thread-safety as something we can just blindly apply to a property.

Without being able to find a single universal answer to those questions, there is no good way of providing a single universal implementation, and any such [Threadsafe] attribute would be of very limited value at best. Finally, at the psychological level of the programmer using it, it is very likely to lead to a false sense of security that they have created a thread-safe class when in fact they have not; which would make it actually worse than useless.