locking the object inside a property, c#

开发者_JAVA百科public ArrayList InputBuffer
{
    get { lock (this.in_buffer) { return this.in_buffer; } }
}

is this.in_buffer locked during a call to InputBuffer.Clear?

or does the property simply lock the in_buffer object while it's getting the reference to it; the lock exits, and then that reference is used to Clear?

No, the property locks the reference while it's getting that reference. Pretty pointless, to be honest... this is more common:

private readonly object mutex = new object();
private Foo foo = ...;

public Foo Foo
{
    get
    {
        lock(mutex)
        {
            return foo;
        }
    }
}

That lock would only cover the property access itself, and wouldn't provide any protection for operations performed with the Foo. However, it's not the same as not having the lock at all, because so long as the variable is only written while holding the same lock, it ensures that any time you read the Foo property, you're accessing the most recent value of the property... without the lock, there's no memory barrier and you could get a "stale" result.

This is pretty weak, but worth knowing about.

Personally I try to make very few types thread-safe, and those tend to have more appropriate operations... but if you wanted to write code which did modify and read properties from multiple threads, this is one way of doing so. Using volatile can help too, but the semantics of it are hideously subtle.

The object is locked inside the braces of the lock call, and then it is unlocked.

In this case the only code in the lock call is return this.in_buffer;.

So in this case, the in_buffer is not locked during a call to InputBuffer.Clear.

One solution to your problem, using extension methods, is as follows.

private readonly object _bufLock;
class EMClass{
    public static void LockedClear(this ArrayList a){
        lock(_bufLock){
            a.Clear();
        }
    }
}

Now when you do:

a.LockedClear();

The Clear call will be done in a lock.

You must ensure that the buffer is only accessed inside _bufLocks.

In addition to what others have said about the scope of the lock, remember that you aren't locking the object, you are only locking based on the object instance named.

Common practice is to have a separate lock mutex as Jon Skeet exemplifies.

If you must guarantee synchronized execution while the collection is being cleared, expose a method that clears the collection, have clients call that, and don't expose your underlying implementation details. (Which is good practice anyway - look up encapsulation.)