有没有重写可以使这个c＃类线程安全？

Question

I love the quick way of creating classes in C# where we can easily create Members without having to implement the get and set code but (as far as I know) they are not thread safe!

public class SocksEntry
{
    public int Int1 { get; set; }
    public int Int2 { get; set; }
}

Does C# provide a quick an easy way of adding thread safety without having to do this?

public class SocksEntry
{
    protected object _lock = new object();

    // internal
    private int _int1 = 0;
    private int _int2 = 0;

    // accessors
    protected int Int1
    {
        get { lock (_lock) return _int1; }
        set { lock (_lock) _int1 = value; }
    }

    protected int Int2
    {
        get { lock (_lock) return _int2; }
        set { lock (_lock) _int2 = value; }
    }
}

It obviously makes the whole class a lot bigger and a pain to create compared to the non-thread safe version!

Answer 1

Making a class thread safe is a lot harder than you might even imagine. It might not be enough to put locks around the getters and setters. So the best practice is to have the class not-thread safe and leave the responsibility to the consumer of this class to synchronize the access to it if he needs thread safety. If the consumer doesn't need thread safety, then great, you won't be penalizing the performance of the application just because you built thread safety into the class without even needing it. Why do you think that 99.99% of the classes in .NET are not thread-safe?

Answer 2

In a word, no.

Auto-implemented properties are great, but when one hits the limitations, that's it.

However, you could create a Visual Studio snippet (like prop ) that would write the boiler-plate code for you.

Answer 3

I think the thread safety problem you're referring to is something like this:

public int Value { get; set; }

public void Foo()
{
    if (this.Value > 0)   // Read the property and make a decision based on its present value
    {
        // Do something with the property, assuming its value has passed your test.
        // Note that the property's value may have been changed by another thread between the previous line and this one.
        Console.WriteLine(this.Value);
    }
}

The problem is that the property value may have changed between when you examined it and when you use it. This happens whether you use auto properties, backing variables, or the locks you have in your question. The correct solution depends on how you need your application to behave (what should it do if the value has changed between one line and another). A common solution is to cache the value right in the function where you're using it:

public int Value { get; set; }

public void Foo()
{
    int cachedValue = this.Value;

    if (cachedValue  > 0)
    {
        Console.WriteLine(cachedValue );
    }
}

However, that won't necessarily be correct for what your app is supposed to do.

Answer 4

Most easier and ofthen the only one right approach is to make a class immutable , so only read operations are available.

public sealed class SocksEntry
{
    public int Int1 { get; private set; }
    public int Int2 { get; private set; }
}

But if this is not possible for a particular business entity - expose some business methods rather than property setters, then it is much easier to sync entire method (think transaction) rather than each property setter which sometimes makes sense set alltogether

// lock entire business transaction if possible
public void UpdateEntity(int a, int b)
{
   lock (entityLock)
   {
       Int1 = a;
       Int2 = b;
    }
}    

Answer 5

In the .NET memory model, reads and writes of native integer types less than or equal to the size of your platform's pointer (ie int on 32-bit, long on 64-bit) are atomic. Atomic means you can read and write it without using locks, and you'll never read or write an incomplete (ie half-way between a write) value.

However, .NET does not guarantee that writes will be immediately visible to other threads (meaning you can write in thread A, then read in thread B, and still read an old value). On x86 you get immediate visibility with the architecture, but on other platforms you need to use a volatile field or Thread.MemoryBarrier after writes. lock inserts a memory barrier for you, so you don't need to worry about it.

Another thing to think of is how you use the class. While a single access is atomic, a lock will still be needed if you want to read or write multiple fields as one atomic operation. (well, not technically always -- there are certain optimizations you can sometimes do, but stick to the simple stuff while you're learning)

So in short: the lock there is quite overkill -- you can get rid of it and use volatile/barriers if you require immediate visibility.