haskell 频道“Control.Concurrent.Chan”对多个读者/生产者安全吗？答案

【问题标题】：Are haskell channels `Control.Concurrent.Chan` safe for multiple readers/producers?haskell 频道“Control.Concurrent.Chan”对多个读者/生产者安全吗？
【发布时间】：2012-03-25 20:50:34
【问题描述】：

我需要建立一个并发系统，在线程之间共享一个Control.Concurrent.Chan。将只有一个消费者和许多生产者。查看Chan documentation，我没有看到任何关于可能在同一频道上工作的消费者和生产者数量的警告，并且源代码似乎使用MVars 的默认“安全”访问器，因此我认为假设不应该有限制应该是安全的，但我不确定。所以，我的问题是……你知道 Haskell 频道对于多个读者和制作人来说是否安全（通常）？

【问题讨论】：

标签： haskell concurrency atomic

【解决方案1】：

它们对于任意数量的线程都是安全的。它们是一个简单的基于 MVar 的链表。设计权衡允许 dupChan 有助于在相反的情况下向多个读者广播。

Chan 很简单，它不计算里面的物品数量，也没有上限。因此，如果生产者超过消费者，那么陈将变得非常非常大。如果这是一个问题，那么您可以将 Chan 与 (MVar Int) 配对。并让生产者和消费者修改 Chan 中的项目总数。

【讨论】：

好的，谢谢。在我的情况下，没有上限不是问题，因为每个线程在完成后将发送一条且仅一条消息。这是一个简单的结构，我将使用它让主线程在继续之前等待来自通道的 N 条消息（如果 N 是线程数）。
这样的计数障碍看起来像一个数量信号量，您可以使用 (1-N) 的初始数量将 Chan 的链表长度替换为 hackage.haskell.org/package/SafeSemaphore 中的 MSem 或 MSemN。
我不知道haskell平台的信号量，非常感谢您指出。我肯定会用它们替换频道。
当然，如果您确实添加了一个单独的 MVar 变量，那么您编写的代码就是带有锁的所有缺点。您可以考虑改用TChan 和TVar（即使用软件事务内存）。
我发现与简单的 MVar 相比，STM 并没有提高性能。如果 STM 替代方案锁定了许多 MVar 的一个大子集，那么也许 STM 会表现得更好。如果 STM 允许许多并发读取器（乐观地）和偶尔写入，那么也许 STM 会执行得更好。但是 STM 更容易正确使用。