Best Practices in using a lock

Question

Suppose I have the following property in some class, and its purpose is to be used as a lock.

protected object SyncRoot { get; private set; }

Anyways, regardless of how and if this was set. What is best practice to go about using it if it is, in fact, set?

Since lock does not work with null objects, should I handle it like this?

lock (SyncRoot ?? new object())
    SomeMethod();

Or should I check for null like this?

if (SyncRoot != null)
    lock (SyncRoot)
        SomeMethod();
else
    SomeMethod();

If it is, in fact, set, I'd want to use it to lock. Otherwise, I don't care. Is the first solution inefficient or redundant in anyway?

EDIT: All these answers are good. However, I can only pick one. Given my situation as discussed with Luke, there is no reason why my SyncRoot should be null. The overhead of a lock in a single threaded environment is no biggy, but necessary if in a multi-threaded one.

(Vote ups for all 4 of ya) Thank you all for your speedy replies.

Answer 1

I normally use a private member variable not a property, ie

private static object MyLock = new object();

This way its always initialised.

You can also use a non static version such as

private readonly object MyLock = new object();

Answer 2

Synchronizing on

SyncRoot ?? new object()

makes no sense, because if SyncRoot is null, each thread will get a new object every time. Synchronizing on separate objects has no effect: threads will continue right away, because nobody else could possibly synchronize on the same new object.

You should initialize SyncRoot in the constructor, before the first thread tries to obtain a lock.