创建在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。

最后，通过引用中的互斥量（虽然我认为它是一个错字）。