6

我需要实现（在 C++ 中）一个线程安全的容器，使得只有一个线程能够从容器中添加或删除项目。我以前通过在线程之间共享互斥体来完成这种事情。这导致我的代码中到处都是互斥对象，使事情变得非常混乱且难以维护。

我想知道是否有一种更整洁、更面向对象的方式来做到这一点。我想到了以下围绕容器的简单类包装器（半伪 C++ 代码）

 class LockedList {
    private:
        std::list<MyClass> m_List;

    public:
        MutexObject Mutex;
 };

这样锁定可以通过以下方式完成

 LockedList lockableList;     //create instance
 lockableList.Mutex.Lock();    // Lock object

 ... // search and add or remove items

 lockableList.Mutex.Unlock();   // Unlock object

所以我的问题真的是从设计的角度问这是否是一个好方法？我知道从设计的角度来看，允许公众访问成员是不受欢迎的，上述设计是否有任何严重的缺陷。如果是这样，是否有更好的方法来实现线程安全的容器对象？

总的来说，我读过很多关于设计和 C++ 的书籍，但似乎确实缺乏关于多线程编程和多线程软件设计的文献。

如果上述方法是解决问题的糟糕方法，那么任何人都可以提出改进方法，或者向我指出一些信息，这些信息解释了将类设计为线程安全的好方法？？？非常感谢。

4

6 回答 6

7

我会做这样的事情，通过使用 RAII 使其更加安全。

class LockedList {
private:
    std::list<MyClass> m_List;
    MutexObject Mutex;
    friend class LockableListLock;
};

class LockableListLock {
private:
    LockedList& list_;
public:
    LockableListLock(LockedList& list) : list_(list) { list.Mutex.Lock(); }
    ~LockableListLock(){ list.Mutex.Unlock(); }
}

你会像这样使用它

LockableList list;
{
    LockableListLock lock(list); // The list is now locked.

    // do stuff to the list

} // The list is automatically unlocked when lock goes out of scope.

您还可以通过在 LockableListLock 中的 std::list 接口周围添加包装器，让该类强制您在对其进行任何操作之前锁定它，这样您就可以通过 LockableListLock 类访问列表，而不是通过 LockedList 类访问列表。例如，您可以在 std::list::begin() 周围制作这个包装器

std::list::iterator LockableListLock::begin() {
    return list_.m_List.begin();
}

然后像这样使用它

LockableList list;
LockableListLock lock(list);
// list.begin();   //This is a compiler error so you can't 
                   //access the list without locking it
lock.begin(); // This gets you the beginning of the list
于 2012-08-01T16:01:36.723 回答
7

我宁愿设计一个资源所有者来锁定互斥体并返回一个线程可以使用的对象。一旦线程完成并停止使用该对象，资源将automatically返回给其所有者并释放锁。

template<typename Resource>
class ResourceOwner
{
      Lock         lock; 
      Resource     resource;

      public:
         ResourceHolder<Resource>  getExclusiveAccess()
         {
              // Let the ResourceHolder lock and unlock the lock
              // So while a thread holds a copy of this object only it
              // can access the resource. Once the thread releases all
              // copies then the lock is released allowing another
              // thread to call getExclusiveAccess().
              //
              // Make it behave like a form of smart pointer
              //    1) So you can pass it around.
              //    2) So all properties of the resource are provided via ->
              //    3) So the lock is automatically released when the thread
              //       releases the object.

              return ResourceHolder<Resource>(lock, resource);
         }
};

资源持有者（没有经过深思熟虑，因此可以改进）

template<typename Resource>
class ResourceHolder<
{
    // Use a shared_ptr to hold the scopped lock
    // When first created will lock the lock. When the shared_ptr
    // destroyes the scopped lock (after all copies are gone)
    // this will unlock the lock thus allowding other to use
    // getExclusiveAccess() on the owner
    std::shared_ptr<scopped_lock>    locker;
    Resource&                        resource;   // local reference on the resource.

    public:
        ResourceHolder(Lock& lock, Resource& r)
            : locker(new scopped_lock(lock))
            , resource(r)
        {}

        // Access to the resource via the -> operator
        // Thus allowing you to use all normal functionality of 
        // the resource.
        Resource* operator->() {return &resource;}
};

现在一个可锁定的列表是：

ResourceOwner<list<int>>  lockedList;

void threadedCode()
{
    ResourceHolder<list<int>>  list = lockedList.getExclusiveAccess();

    list->push_back(1);
}
// When list goes out of scope here. 
// It is destroyed and the the member locker will unlock `lock`
// in its destructor thus allowing the next thread to call getExclusiveAccess()
于 2012-08-01T16:06:47.857 回答
2

好的，我将更直接地说明其他人已经暗示的内容：这种设计的至少一部分，很可能是全部，可能不是您想要的。至少，您需要 RAII 样式的锁定。

我还将locked（或任何您喜欢的名称）制作为模板，因此您可以将锁定与容器本身分离。

// C++ like pesudo-code. Not intended to compile as-is.
struct mutex {
    void lock() { /* ... */ }
    void unlock() { /* ... */ }
};

struct lock {
    lock(mutex &m) { m.lock(); }
    ~lock(mutex &m) { m.unlock(); }
};

template <class container>
class locked {
    typedef container::value_type value_type;
    typedef container::reference_type reference_type;
    // ...

    container c;
    mutex m;
public:
    void push_back(reference_type const t) {
        lock l(m);
        c.push_back(t);
    }

    void push_front(reference_type const t) { 
        lock l(m);
        c.push_front(t);
    }

    // etc.
};

这使得代码相当容易编写并且（至少在某些情况下）仍然可以获得正确的行为——例如，您的单线程代码可能看起来像这样：

std::vector<int> x;

x.push_back(y);

...您的线程安全代码如下所示：

locked<std::vector<int> > x;

x.push_back(y);

假设您提供通常begin()的 , end(), push_front,push_back等，您locked<container>仍然可以像普通容器一样使用，因此它适用于标准算法、迭代器等。

于 2012-08-01T16:22:27.407 回答
1

这种方法的问题在于它使 LockedList 不可复制。有关此障碍的详细信息，请查看此问题：

设计一个线程安全的可复制类

多年来我尝试了各种方法，在容器声明旁边声明的互斥锁总是最简单的方法（一旦在天真地实现其他方法后修复了所有错误）。

你不需要用互斥锁“乱扔”你的代码。你只需要一个互斥锁，在它保护的容器旁边声明。

于 2012-08-01T16:02:12.760 回答
0

很难说粗粒度锁定是一个糟糕的设计决策。我们需要了解代码所在的系统才能讨论这个问题。如果您不知道它不起作用，这是一个很好的起点。先做最简单的事情。

如果您在未解锁的情况下进行范围检查，则可以通过降低失败的可能性来改进该代码。

struct ScopedLocker {
  ScopedLocker(MutexObject &mo_) : mo(mo_) { mo.Lock(); }
  ~ScopedLocker() { mo.Unlock(); }

  MutexObject &mo;
};

您还可以对用户隐藏实现。

class LockedList {
  private:
    std::list<MyClass> m_List;
    MutexObject Mutex;

  public:
    struct ScopedLocker {
       ScopedLocker(LockedList &ll);
       ~ScopedLocker();
    };
};

然后，您只需将锁定列表传递给它，而无需他们担心MutexObject.

您还可以让列表在内部处理所有锁定，这在某些情况下是可以的。设计问题是迭代。如果列表在内部锁定，那么这样的操作比让列表的用户决定何时锁定要糟糕得多。

void foo(LockedList &list) {
  for (size_t i = 0; i < 100000000; i++) {
    list.push_back(i);
  }
}

一般来说，由于这样的问题，这是一个很难给出建议的话题。更多的时候，更多的是关于你如何使用一个对象。当您尝试编写解决多处理器编程的代码时，会有很多泄漏的抽象。这就是为什么您会看到更多工具包让人们编写满足他们需求的解决方案。

有一些书讨论了多处理器编程，尽管它们很少。随着所有新的 C++11 特性的出现，未来几年应该会有更多的文献出现。

于 2012-08-01T15:43:45.000 回答
0

我想出了这个（我确信可以改进它以采用两个以上的参数）：

template<class T1, class T2>
class combine : public T1, public T2
{
public:

    /// We always need a virtual destructor.
    virtual ~combine() { }
};

这允许您执行以下操作：

    // Combine an std::mutex and std::map<std::string, std::string> into
    // a single instance.
    combine<std::mutex, std::map<std::string, std::string>> mapWithMutex;

    // Lock the map within scope to modify the map in a thread-safe way.
    {
        // Lock the map.
        std::lock_guard<std::mutex> locked(mapWithMutex);

        // Modify the map.
        mapWithMutex["Person 1"] = "Jack";
        mapWithMutex["Person 2"] = "Jill";
    }

如果您希望使用 std::recursive_mutex 和 std::set，那也可以。

于 2018-01-26T19:24:05.413 回答