12

首先，一些背景。我想要一个队列，我想以两种不同模式之一操作。在第一种模式下，如果队列中存在一个元素，我希望能够检索一个元素，但如果没有元素，则不阻塞。在第二种模式下，我希望能够阻塞直到队列有一个元素。（我知道我可以为每种模式使用专门的机制，但我想排除一些通用代码，因此如果我可以对两种操作模式使用相同的机制，那将是最简单的。）

我可以使用Chan，但根据文档，我不应该使用isEmptyChan它，因为由于可能出现死锁，它已被弃用。这给我留下了TChan. 该tryReadTChan函数为我提供了我想要的第一种模式（即我可以检查元素是否存在而不阻塞），但我不确定究竟是什么readTChan。我的心智模型是，该atomically块将不断重试，直到通道中出现一个元素，这意味着它会忙于循环浪费 CPU 周期；这与readChan（即非 STM 版本）不同，后者（如果我理解正确的话）实际上会阻塞线程的执行，直到元素可用，因为运行时线程调度程序可以理解 MVar。

TChan就像这样，Chan如果我使用readTChan运行时足够聪明，不会在值可用之前调度调用线程？还是会浪费大量 CPU 周期不断轮询一个值到达？

4

2 回答 2

15

STM 阻塞（通过retry）的行为就像它立即重试事务一样，但实现更智能：由于 STM 会跟踪您在事务进行时读取的变量，它知道事务的行为方式相同，只要这些变量具有相同的值。因此，当事务失败时，它会阻塞（实际上不会重试），直到您使用的变量之一发生更改。在TChans 的情况下，这意味着它会阻塞，直到有人写入TChan.

我推荐 Simon Marlow 关于并发和并行 Haskell 的幻灯片，以很好地介绍 STM（以及其他内容）。

于 2013-01-27T07:49:06.577 回答
11

您的心智模型具有正确的指称语义，但错过了 STM 所做的操作优化。当一个事务在 STM 中重试时，它会阻塞，直到TVar它在重试之前读取的一些内容被更改。（是的，TChan是根据TVar.）

因此，执行事务与事务不断重试具有相同的含义——但 STM 系统足够智能，不会在事务中发生不同情况的情况下不忙循环。

于 2013-01-27T07:47:13.457 回答