C# thread safety with get/set

Question

This is a detail question for C#.

Suppose I've got a class with an object, and that object is protected by a lock:

Object mLock = new Object(); MyObject property; public MyObject MyProperty {     get {          return property;     }     set {           property = value;      } } 

I want a polling thread to be able to query that property. I also want the thread to update properties of that object occasionally, and sometimes the user can update that property, and the user wants to be able to see that property.

Will the following code properly lock the data?

Object mLock = new Object(); MyObject property; public MyObject MyProperty {     get {          lock (mLock){              return property;          }     }     set {           lock (mLock){               property = value;           }     } } 

By 'properly', what I mean is, if I want to call

MyProperty.Field1 = 2; 

or whatever, will the field be locked while I do the update? Is the setting that's done by the equals operator inside the scope of the 'get' function, or will the 'get' function (and hence the lock) finish first, and then the setting, and then 'set' gets called, thus bypassing the lock?

Edit: Since this apparently won't do the trick, what will? Do I need to do something like:

Object mLock = new Object(); MyObject property; public MyObject MyProperty {     get {          MyObject tmp = null;          lock (mLock){              tmp = property.Clone();          }          return tmp;     }     set {           lock (mLock){               property = value;           }     } } 

which more or less just makes sure that I only have access to a copy, meaning that if I were to have two threads call a 'get' at the same time, they would each start with the same value of Field1 (right?). Is there a way to do read and write locking on a property that makes sense? Or should I just constrain myself to locking on sections of functions rather than the data itself?

Just so that this example makes sense: MyObject is a device driver that returns status asynchronously. I send it commands via a serial port, and then the device responds to those commands in its own sweet time. Right now, I have a thread that polls it for its status ("Are you still there? Can you accept commands?"), a thread that waits for responses on the serial port ("Just got status string 2, everything's all good"), and then the UI thread which takes in other commands ("User wants you to do this thing.") and posts the responses from the driver ("I've just done the thing, now update the UI with that"). That's why I want to lock on the object itself, rather than the fields of the object; that would be a huge number of locks, a, and b, not every device of this class has the same behavior, just general behavior, so I'd have to code lots of individual dialogs if I individualized the locks.

Answer 1

No, your code won't lock access to the members of the object returned from MyProperty. It only locks MyProperty itself.

Your example usage is really two operations rolled into one, roughly equivalent to this:

// object is locked and then immediately released in the MyProperty getter MyObject o = MyProperty;  // this assignment isn't covered by a lock o.Field1 = 2;  // the MyProperty setter is never even called in this example 

In a nutshell - if two threads access MyProperty simultaneously, the getter will briefly block the second thread until it returns the object to the first thread, but it'll then return the object to the second thread as well. Both threads will then have full, unlocked access to the object.

EDIT in response to further details in the question

I'm still not 100% certain what you're trying to achieve, but if you just want atomic access to the object then couldn't you have the calling code lock against the object itself?

// quick and dirty example // there's almost certainly a better/cleaner way to do this lock (MyProperty) {     // other threads can't lock the object while you're in here     MyProperty.Field1 = 2;     // do more stuff if you like, the object is all yours } // now the object is up-for-grabs again 

Not ideal, but so long as all access to the object is contained in lock (MyProperty) sections then this approach will be thread-safe.