Quy ước đặt tên cho các đối tượng khóa chủ đề chuyên dụng [đóng]

Một câu hỏi tương đối nhỏ, nhưng tôi chưa thể tìm thấy tài liệu chính thức hoặc thậm chí ý kiến ​​/ thảo luận trên blog về nó.

Nói một cách đơn giản: khi tôi có một đối tượng riêng tư với mục đích duy nhất là phục vụ riêng tư lock, tôi sẽ đặt tên cho đối tượng đó là gì?

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

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

Chúng ta nên đặt tên LockingObjectở đây là gì? Cũng xem xét không chỉ tên của biến mà còn trông như thế nào trong mã khi khóa.

Tôi đã thấy nhiều ví dụ khác nhau, nhưng dường như không có lời khuyên chắc chắn nào:

1. Rất nhiều cách sử dụng SyncRoot(và các biến thể như _syncRoot).

   • Mẫu mã: lock(SyncRoot) ,lock(_syncRoot)
   • Điều này dường như bị ảnh hưởng bởi SyncLocktuyên bố tương đương của VB , thuộc SyncRoottính tồn tại trên một số lớp ICollection và một phần của một kiểu mẫu thiết kế SyncRoot (có thể cho là ý tưởng tồi)
   • Ở trong bối cảnh C #, không chắc tôi có muốn đặt tên VBish không. Thậm chí tệ hơn, trong VB đặt tên biến giống như từ khóa. Không chắc đây có phải là một nguồn gây nhầm lẫn hay không.

2. thisLockvà lockThistừ các bài viết MSDN: Tuyên bố khóa C # , Tuyên bố VB SyncLock

   • Mẫu mã: lock(thisLock) ,lock(lockThis)
   • Không chắc chắn nếu những cái này được đặt tên tối thiểu hoàn toàn cho ví dụ hay không
   • Thật kỳ lạ nếu chúng ta sử dụng điều này trong một staticlớp / phương thức.
   • EDIT: Bài viết Wikipedia về khóa cũng sử dụng cách đặt tên này cho ví dụ của nó

3. Một số cách sử dụng PadLock(của vỏ khác nhau)

   • Mẫu mã: lock(PadLock) ,lock(padlock)
   • Không tệ, nhưng thịt bò duy nhất của tôi là nó không gây ngạc nhiên khi gọi hình ảnh của một "ổ khóa" vật lý mà tôi có xu hướng không liên kết với khái niệm luồng trừu tượng .

4. Đặt tên khóa dựa trên những gì nó dự định khóa

   • Mẫu mã: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
   • Trong ví dụ trang VB SyncRoot MSDN, nó có một simpleMessageListví dụ với một messagesLockđối tượng riêng tư
   • Tôi không nghĩ nên đặt tên cho khóa theo loại bạn đang khóa ("DictionaryLock") vì đó là một chi tiết triển khai có thể thay đổi. Tôi thích đặt tên xung quanh khái niệm / đối tượng bạn đang khóa ("MessagesLock" hoặc "commandQueueLock")
   • Thật thú vị, tôi rất hiếm khi thấy quy ước đặt tên này để khóa các đối tượng trong các mẫu mã trực tuyến hoặc trên StackOverflow.

5. (EDIT) Thông số C # trong phần "8.12 Tuyên bố khóa" có ví dụ về mẫu này và đặt tên cho mẫu này synchronizationObject

   • Mẫu mã: lock(SynchronizationObject) ,lock(synchronizationObject)

Câu hỏi: Ý kiến ​​của bạn nói chung về việc đặt tên các đối tượng khóa riêng là gì?

Gần đây, tôi đã bắt đầu đặt tên cho chúng ThreadLock(giống như tùy chọn 3), nhưng tôi thấy mình đang đặt câu hỏi cho cái tên đó.

Tôi thường xuyên sử dụng mẫu khóa này (trong mẫu mã được cung cấp ở trên) trong các ứng dụng của mình vì vậy tôi nghĩ rằng có thể có ý kiến ​​/ thảo luận chuyên nghiệp hơn về quy ước đặt tên vững chắc cho chúng. Cảm ơn!

Tôi đã đưa đến thói quen gọi đó là SomeResourceLocknơi mà SomeResourcelà những gì bạn cần khóa truy cập / cập nhật, tức là (tha thứ cho bất kỳ vấn đề chủ đề, đây chỉ là một minh hoạ)

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
    }
}

Tôi đã có thói quen này sau khi có các lớp nơi tôi có thể có nhiều khóa cho các tài nguyên khác nhau, vì vậy tôi đặt tên cho đối tượng khóa dựa trên tài nguyên mà nó khóa truy cập. Đôi khi một đối tượng có thể khóa nhiều tài nguyên trong trường hợp đó tôi sẽ cố gắng làm cho các tên tôn trọng điều đó theo một cách nào đó, để người đọc biết "các khóa khác cho các tài nguyên riêng lẻ đó cũng sẽ tranh chấp với khóa này".

Tôi thường gọi nó locker, nhưng vì nó là riêng tư, tôi tin rằng đó là một chi tiết triển khai không quan trọng. Nguyên tắc đầu tiên, sử dụng các tiêu chuẩn của nhóm / công ty của bạn. Nếu không có, tốt, hãy tạo một cái và sử dụng nó, nhưng trong việc làm cho nó, hãy giữ mọi thứ đơn giản. Nếu lớp của bạn có một đối tượng khóa duy nhất, gọi nó foolà đủ tốt. Nếu bạn có nhiều, một đơn đặt hàng kinh doanh tốt có thể chỉ cần xem lại thiết kế của lớp đó trước để xem liệu nó có làm quá nhiều thứ khác nhau không. Nhưng, nếu không, thì cái tên trở nên quan trọng, như trong ví dụ hoàn toàn bị chiếm đoạt này:

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...
            }
        }
    }
}

Tôi luôn luôn sử dụng lck_. Theo cách đó, nếu bạn ctrl + f 'lck' thì bạn chỉ nên tìm các khóa trong khi 'khóa' cũng sẽ tìm thấy những thứ như 'đồng hồ'.

Những thứ như lock This và Padlock đều ổn đối với danh mục đầu tư của uni nhưng đối với các dự án phù hợp, bạn thực sự nên sử dụng tên ngữ nghĩa để khi bạn nhìn vào các khai báo, bạn biết đối tượng thực sự làm gì mà không cần tìm kiếm thông qua mã.