多个进程推送元素以列出STL C++

Multiple processes pushing elements to list STL C++

本文关键字：STL C++ 元素 进程      更新时间：2023-10-16

我有多个预处理的服务器进程，它们接受修改服务器上共享STL C++列表的请求。每个进程只是在列表末尾推送一个新元素，然后返回迭代器。

我不确定每个进程应该如何尝试获取列表上的锁定？它应该在整个对象上，还是STL列表能够处理并发，因为我们只是在列表的末尾推送一个元素？

假设您指的是线程而不是进程，您可以共享STL容器，但需要注意同步。STL容器在一定程度上是线程安全的，但您需要了解给定的线程安全保证：

  1. 一个容器可以由多个读取器同时使用
  2. 如果一个容器有一个写入程序，则既不应该有并发的读取器，也不应该有并行的写入程序
  3. 保证是针对每个容器的，即线程可以同时使用不同的容器，而不需要它们之间的同步

这些限制的原因是容器的接口是为了在一个线程内高效使用，并且您不想阻碍非共享容器的处理，因为它可能会在多个线程之间共享。此外，容器接口不适合任何类型的容器维护并发机制。例如，仅仅因为v.empty()刚刚返回false，并不意味着v.pop()工作，因为容器现在可能是空的：如果有内部同步，那么一旦empty()返回，任何锁都会被释放，并且在调用pop()时可以更改容器。

创建用于不同线程之间通信的队列相对容易。它将使用std::mutex和std::condition_variable的合适的实例化。我认为有人建议将类似的内容包含到标准中，但它还不是标准C++库的一部分。但是，请注意，这样的类不会向插入的元素返回迭代器，因为当您访问它时，该元素可能会再次消失，而且迭代器的用途也不确定。

在多个进程之间进行这种同步的机制需要开发人员处理几个问题。首先，流程之间共享的内容都需要在流程之外设置。这通常意味着在实践中使用shared memory。

然后，这些进程需要在访问被共享的存储器方面相互通信。毕竟，如果一个线程开始处理共享的数据结构，但在完成操作之前被交换掉，那么数据就会不一致。

这种同步可以使用linux中的信号量等操作系统结构来完成，并允许竞争进程进行协调。

有关基于linux的IPC的详细信息，请参阅此请参阅此以了解基于Windows的IPC详细信息

为了获得一些参考，您可以使用Boost.Interprocess文档，该文档提供了IPC机制的独立于平台的实现。

标准库容器不提供针对并发修改的automagic保护，因此每次访问队列都需要全局锁。

您甚至必须小心迭代器或对列表元素的引用，因为您可能不一定知道相应的元素何时从列表中删除。

相关文章：