问题标签 [ioref]

这段代码究竟做了什么？someMap对象 (of ::Data.Map.Strict.Map) 的副本是由引用myMap还是仅作为引用？我的意思是在我阅读后可以someMap改变（通过另一个线程）readIORef？像 C 的 volatile 之类的东西……有可能吗？我希望它是复制/快照，因此任何更改都不会影响我的someMap, 或 ...？

如果我知道 a 的大小是 x，我想知道 IORef a 类型的变量的内存占用是多少。此外，与 Java 中的常规变量赋值（如 x = 3）相比，应用于整数的函数 writeIORef 的预期性能是什么？

这对我来说完全是一个惊喜。readIORef当有atomicModifyIORef飞行时，有人可以解释阻塞背后的原因是什么吗？我知道假设是提供给后一个函数的修改函数应该非常快，但这不是重点。

这是一个示例代码，它重现了我正在谈论的内容：

运行这段代码会产生：

请注意，readIORef: Wating ...它只打印两次，一次是在阻塞之前，一次是在阻塞之后。这是非常出乎意料的，因为它是一个在完全独立的线程中运行的动作。这意味着阻塞IORef会影响其他线程而不是调用的线程readIORef，这更令人惊讶。

这些语义是预期的，还是一个错误？我适合不是错误，为什么这是预期的？稍后我会打开一个 ghc 错误，除非有人对此行为有我想不出的解释。这是 ghc 运行时的一些限制，我不会感到惊讶，在这种情况下，我稍后会在这里提供答案。无论结果如何，了解这种行为都非常有用。

编辑 1

在评论中请求了我尝试过的不需要的繁忙循环unsafePerformIO，所以在这里

结果完全相同，只是运行时略有不同。

编辑 2

事实证明，这sayString是没有输出没有出现的原因。这是 outsayString被交换时的内容putStrLn：

那仍然没有回答问题，为什么要readIORef阻止。事实上，我偶然发现了 Samuli Thomasson 的《Haskell High Performance》一书中的一句话，它告诉我们不应该发生阻塞：

在 GHCI（版本 9.0.1）中，以下给出了我所期望的：

但是当我以这种方式尝试同样的事情时：

返回一个空列表，就好像修改从未发生过一样。为什么会这样？输出不应该相同吗？