如何使公共属性线程安全？

Question

I'm implementing the BackgroundWorker replacement for some reason, and I have to implement following public properties:

public bool CancellationPending { get; private set; }
public bool IsBusy { get; private set; }
public bool WorkerReportsProgress { get; set; }
public bool WorkerSupportsCancellation { get; set; }

I'm sure you know what purpose they serve in BackgroundWorker . So they might be accessed/modified by different threads. I'm concerned about how to "protect" them for multithreading. I thought declaring them as volatile would be enough, but volatile can't be applied to automatic properties.

What should I do? Should I create private fields for these properties, and declare them volatile ? Or should I use lock ing inside each get and set blocks?

I think this should be pretty common scenario - making properties (preferably automatic properties) thread-safe. Note that all properties are of atomic type in this example.

EDIT:

To clarify what I need: I need to be sure that all threads always read the most up-to-date value of the property. See this: https://stackoverflow.com/a/10797326/1081467

So again, do you advice using volatile , or lock ing, or anything else?.. When using the bool properties atomicity is guaranteed, so only the second problem is left (reading the up-to-date values), so how do you solve this correctly? What about when you have properties of non-primitive types? Do you put lock s in each get and set blocks?

Answer 1

I came up with the following implementation. Please comment whether you think it is an optimal solution:

//========== Public properties ==================================================//

public bool CancellationPending { get { return _cancellationPending; } private set { _cancellationPending = value; } }

public bool IsBusy { get { return _isBusy; } private set { _isBusy = value; } }

public bool WorkerReportsProgress { get { return _workerReportsProgress; } set { _workerReportsProgress = value; } }

public bool WorkerSupportsCancellation { get { return _workerSupportsCancellation; } set { _workerSupportsCancellation = value; } }

//========== Private fields ==================================================//

private volatile bool _cancellationPending;
private volatile bool _isBusy;
private volatile bool _workerReportsProgress;
private volatile bool _workerSupportsCancellation;

Reasoning: atomicity is ensured by the fact that the fields are of type bool , so no need for lock ing. Making them volatile will ensure that any thread will read current value - not cached - in case another thread has modified it. I think this is the exact purpose (and only valid use) of volatile keyword, right?

Answer 2

public bool CancellationPending { get; private set; }
public bool IsBusy { get; private set; }
public bool WorkerReportsProgress { get; set; }
public bool WorkerSupportsCancellation { get; set; }

So they might be accessed/modified by different threads

No, that would only apply to CancellationPending and IsBusy , not to the others.
And they are all booleans, guaranteed to be atomic. Atomicity is enough here.

All of the properties of the original Backgroundworker are documented as not thread-safe.
See near the bottom of this page .

Answer 3

Though I think that there are better options out there such as using Tasks with anothe scheduler as svick mentioned.

Should you want to continue on this path you should definitely use locking and not volatile fields as volatile does not do what you think . Oh and this guy said something about never making a volatile field...

Instead of volatile you can use your favourite synch primitive (lock, Mutex, Interlocked, ReaderWriterLockSlim, etc...) depending on the access characteristics.

Answer 4

A simple way is to have mutex objects for each property that you want to be thread safe. In the get and set properties, use a Monitor.Enter(declaredObjectMutext), and Monitor.Exit(declaredObjectMutex). Once done, this will make your properties thread-safe (all calls to get and set will be blocking calls until any other threads are finished).

Another option is to use the Interlocked Class, which allows for thread-safe modification of integers, and bools. If thats all you're using with your properties, its an easy solution.