Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A relatively minor question, but I haven't been able to find official documentation or even blog opinion/discussions on it.

Simply put: when I have a private object whose sole purpose is to serve for private lock, what do I name that object?

class MyClass
{
    private object LockingObject = new object();

    void DoSomething()
    {
        lock(LockingObject)
        {
            //do something
        }
    }
}

What should we name LockingObject here? Also consider not just the name of the variable but how it looks in-code when locking.

I've seen various examples, but seemingly no solid go-to advice:

  1. Plenty of usages of SyncRoot (and variations such as _syncRoot).

    • Code Sample: lock(SyncRoot), lock(_syncRoot)
    • This appears to be influenced by VB's equivalent SyncLock statement, the SyncRoot property that exists on some of the ICollection classes and part of some kind of SyncRoot design pattern (which arguably is a bad idea)
    • Being in a C# context, not sure if I'd want to have a VBish naming. Even worse, in VB naming the variable the same as the keyword. Not sure if this would be a source of confusion or not.
  2. thisLock and lockThis from the MSDN articles: C# lock Statement, VB SyncLock Statement

    • Code Sample: lock(thisLock), lock(lockThis)
    • Not sure if these were named minimally purely for the example or not
    • Kind of weird if we're using this within a static class/method.
    • EDIT: The Wikipedia article on locks also uses this naming for its example
  3. Several usages of PadLock (of varying casing)

    • Code Sample: lock(PadLock), lock(padlock)
    • Not bad, but my only beef is it unsurprisingly invokes the image of a physical "padlock" which I tend to not associate with the abstract threading concept.
  4. Naming the lock based on what it's intending to lock

    • Code Sample: lock(messagesLock), lock(DictionaryLock), lock(commandQueueLock)
    • In the VB SyncRoot MSDN page example, it has a simpleMessageList example with a private messagesLock object
    • I don't think it's a good idea to name the lock against the type you're locking around ("DictionaryLock") as that's an implementation detail that may change. I prefer naming around the concept/object you're locking ("messagesLock" or "commandQueueLock")
    • Interestingly, I very rarely see this naming convention for locking objects in code samples online or on StackOverflow.
  5. (EDIT) The C# spec under section "8.12 The Lock Statement" has an example of this pattern and names it synchronizationObject

    • Code Sample: lock(SynchronizationObject), lock(synchronizationObject)

Question: What's your opinion generally about naming private locking objects?

Recently, I've started naming them ThreadLock (so kinda like option 3), but I'm finding myself questioning that name.

I'm frequently using this locking pattern (in the code sample provided above) throughout my applications so I thought it might make sense to get a more professional opinion/discussion about a solid naming convention for them. Thanks!

share|improve this question

3 Answers 3

up vote 2 down vote accepted

I've taken to the habit of calling it SomeResourceLock where the SomeResource is what you need the lock to access/update, i.e. (forgive any thread issues, this is just an illustration)

public class ProcessDataInQueue
{
    private static Queue<Data> _dataQueue = new Queue<Data>();
    private static object _dataQueueLock = new Object();

    public void AddOneItem(Data itemToAdd)
    {
        lock(_dataQueueLock)
        {
            _dataQueue.Enqueue(itemToAdd);
        }
    }

    public void ProcessOneItem()
    {
        Data itemToProcess = null;
        lock(_dataQueueLock)
        {
            itemToProcess = _dataQueue.Dequeue();
        }
        // ... process itemToProcess
    }
}

I've come upon this habit after having classes where I may have multiple locks for different resources, so I name the locking object based on what resources it's locking access to. Sometimes one object may be locking multiple resources in which case I would try to make the names respect that in some way, so the reader knows "other locks for those individual resources will be in contention with this lock as well".

share|improve this answer
2  
I think this is confusing, because SynchronizationContext is something quite different. –  svick Oct 10 '12 at 18:00
1  
@svick Totally possible I'm misusing the term, I still think being specific about the resource being locked is important but if it makes more sense, I'll edit this to suggest the word "Lock" in place of "SynchronizationContext". –  Jimmy Hoffa Oct 10 '12 at 18:42
1  
@svick Fixed, thanks for correcting me! –  Jimmy Hoffa Oct 10 '12 at 18:43

I always used lck_. That way if you ctrl+f 'lck' then you should only find the locks whilst 'lock' will also find things like 'clock'.

Things like lockThis and Padlock are fine for uni portfolios but for proper projects you should really use semantic names so that when you look at the declarations you know what the object actually does without searching through the code.

share|improve this answer
    
I'm not keen on short forms of names. On the one hand it makes sense to have a unique(ish) naming style to find all usages. On the other hand, and maybe I've been lucky, I haven't had the need to find locks; I imagine if I would have to searching for "lock(" would give me a good enough result with few enough false-positives to easily ignore. –  Chris Sinclair Oct 10 '12 at 18:44

I usually call it locker, but since it's private, I believe it's a somewhat unimportant implementation detail. First rule of thumb, use your team's/company's standards. If there is not one, well, please make one and use it, but in making it, keep things simple. If your class has a single locking object, calling it foo is good enough. If you have many, a good order of business might just be revisiting that class's design first to see if it's doing too many different things. But, if not, then the name becomes important, as in this completely contrived example:

public sealed class CustomerOrders
{
    private readonly object customerLocker = new object();

    private readonly object orderLocker = new object();

    public IEnumerable<Customer> Customers
    {
        get
        {
            lock (this.cutomerLocker)
            lock (this.orderLocker)
            {
                // stuff...
            }
        }

        set
        {
            lock (this.cutomerLocker)
            lock (this.orderLocker)
            {
                // other stuff...
            }
        }
    }

    public IEnumerable<Order> Orders
    {
        get
        {
            lock (this.orderLocker)
            {
                // stuff...
            }
        }

        set
        {
            lock (this.cutomerLocker)
            {
                // different stuff...
            }
        }
    }
}
share|improve this answer
1  
I totally agree with a naming style more or less like this for multiple locking mechanisms. I too had something very similar to this style when I implemented a class with two lockers (also refactored it away later) –  Chris Sinclair Oct 10 '12 at 18:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.