c++ - 为什么传递对 Mutex 类的引用不是一个好的设计？

Question

来自这里:Logic error in my defined Mutex class and the way I use it in producer consumer program - pthreads

the way you pass around references(!) to your mutex class is plainly asking for trouble, it defies any kind of encapsulation.

为什么这是个问题？我应该按值传递然后编写复制构造函数吗？

在这种情况下，缺乏封装会造成什么危害？我应该如何封装什么？

此外，Why is passing references to the Mutex class not a good design?

Passing a reference to the lock is a bad idea -- you don't "use" the lock, you only acquire and then you give it back. Moving it around makes it hard to track your use of the (critical) resource. Passing a reference to a mutex variable rather than a lock is maybe not so bad, but still it makes it harder to know what parts of the program may deadlock, so its something to avoid.

请用简单的语言举例说明 - 为什么传递引用是个坏主意？

Answer 1

我认为这是糟糕的抽象和糟糕的封装。 mutex 通常是在删除复制构造函数的情况下默认构造的，具有引用同一逻辑对象的多个互斥对象很容易出错，即它可能导致死锁和其他竞争条件，因为程序员或读者可以假设它们是不同的实体。

此外，通过指定您正在使用的内部互斥锁，您将公开线程的实现细节，从而破坏 Mutex 类的抽象。如果您使用的是 pthread_mutex_t，那么您很可能会使用内核线程 (pthreads)。

封装也被破坏，因为您的 Mutex 不是一个单独的封装实体，而是分散到多个(可能是悬挂的)引用中。

如果你想将一个pthread_mutex_t封装到一个类中，你可以这样做

class Mutex {
public:
    void lock(); 
    void unlock();

    // Default and move constructors are good! 
    // You can store a mutex in STL containers with these
    Mutex();
    Mutex(Mutex&&);
    ~Mutex();

    // These can lead to deadlocks!
    Mutex(const Mutex&) = delete;
    Mutex& operator= (const Mutex&) = delete;
    Mutex& operator= (Mutex&&) = delete;

private:
    pthread_mutex_t internal_mutex;
};

Mutex 对象旨在在实现文件中声明的共享范围内共享，而不是在本地声明并作为引用在函数中传递。理想情况下，您只会将参数传递给您需要的线程构造函数。传递对在与相关函数(在本例中为线程执行)处于相同“级别”的范围内声明的对象的引用通常会导致代码错误。如果声明互斥锁的范围不再存在会怎样？ mutex 的析构函数是否会使互斥锁的内部实现无效？如果互斥量通过传递进入整个其他模块，并且该模块启动自己的线程并认为互斥量永远不会阻塞，会发生什么情况，这可能会导致严重的死锁。

还有一种情况，你想使用互斥量移动构造函数，比如在互斥量工厂模式中，如果你想创建一个新的互斥量，你将进行一个函数调用，该函数将返回一个互斥量，然后你将添加该互斥量到您的互斥量列表或传递给通过某种共享数据请求它的线程(上述列表对于此共享数据是个好主意)。然而，获得这样一个正确的互斥锁工厂模式可能非常棘手，因为您需要锁定对互斥锁公共(public)列表的访问。尝试应该是一件有趣的事情!

如果作者的意图是避免全局范围，那么在实现文件中将其声明为静态对象一次就足够了。