創建在C互斥鎖櫃類++

Question

這是我迄今所做的：

class mutexLocker 
{ 
    private: 
    /* Declaration of a Mutex variable `mutexA`. */ 
    pthread_mutex_t &mutexA; 

    /* `mutexStatus` holds the return value of the function`pthread_mutex_lock `. 
    This value has to be returned to the callee so we need to preserve it in a class 
    variable. */ 
    int    mutexStatus; 

    /* We need to decide how to deal with the situation when one thread tries to lock then 
    mutex repeatedly. If the mutex is of type recursive, then there won't be any problem for 
    sure, but otherwise the case may result in a deadlock. */ 
    pthread_t  calleeThreadId; 

    public: 
    /* Constructor attempts to lock the desired mutex variable. */ 
    mutexLocker (pthread_mutex_t argMutexVariable, pthread_t threadId) 
    : mutexA (argMutexVariable, calleeThreadId) 
    { 
     /* Return value is needed in order to know whether the mutex has been 
     successfully locked or not. */ 
     int mutexStatus = pthread_mutex_lock (&argMutexVariable); 
    } 

    /* Since the constructor can't return anything, we need to have a separate function 
    which returns the status of the lock. */ 
    int getMutexLockStatus() 
    { 
     return mutexStatus; 
    } 

    /* The destructor will get called automatically whereever the callee's scope ends, and 
    will get the mutex unlocked. */ 
    ~mutexLocker() 
    { 
     pthread_mutex_unlock (&mutexA); 
    } 
}; 

應在DIY互斥鎖櫃類中提供什麼其他功能？

Answer 1

我完全Slavik81的評論表示贊同沒有創造功能，你不必爲使用情況。

儘管如此引用鎖類新的升壓實現可以是在理解它們的接口的共同需求方面的良好起點：http://www.boost.org/doc/libs/1_42_0/doc/html/thread/synchronization.html#thread.synchronization.locks

在標準C++ 11方面介紹std::lock_guard：http://en.cppreference.com/w/cpp/thread/lock_guard

Answer 2

你向後接近這一點。你編寫代碼來解決你面臨的問題。不要編寫代碼來解決你沒有的問題。 「You aren't gonna need it」是一個很好的原則。

除非您有可以解決的問題，否則不應提供其他功能。鑑於你沒有提到過，我假設你沒有這個問題。因此，還沒有其他功能應該添加。

Answer 3

首先，Graeme和Slavik81的答案都非常好（+1）。

現在，至於什麼補充：

• 可能要附加誤差的支持，這取決於你如何處理錯誤。例如，如果您的團隊在鎖定失敗時拋出異常，則該類可能會創建並拋出異常。
• 作爲診斷，您可能要驗證客戶端測試的採集（在析構函數例如assert如果他們從來沒有證實該鎖成功）成功了。
• 你可能想要一個'重試'獲取功能。在拋出異常之前重試更好，imo。就個人而言，如果EBUSY - 我不認爲它是一個程序員的錯誤 - 不要鎖定長鎖！
• 也將你的pthread_mutex_t藏在一個類中 - 禁止複製，賦值等。把它傳給你的儲物櫃。
• 一些客戶可能想要一個簡單的方法來測試成功，而不是評估狀態。取決於你如何使用它。
• 如果您沒有獲取鎖，請勿在dtor解鎖
• 檢查解鎖的結果。確定在這種情況下的錯誤處理。

也許更重要的是 - 確定要刪除：

• 不可複印。明確刪除拷貝表達意圖。
• 刪除operator= - 表示意圖。
• 刪除移動
• calleeThreadId刪除，除非您發現有用。具體來說，考慮你將如何實際實現你提出的錯誤檢測 - 儲物櫃似乎是數據的錯誤位置，imo。我寧願保持這些儲物櫃最小，集中和簡單。
• 額外一英里：防止堆分配;例如刪除operator new/delete的主變體。
• 如果您不重試，則狀態可能爲const。
• threadID，如果你決定保留它，也可能是const。

最後，通過引用中的互斥量（雖然我認爲它是一個錯字）。