当前位置：文江博客话题详情

c++易失性多线程变量

发布于 2024-08-23 14:31:21 字数 221 浏览 10 评论 0原文

我正在编写一个 C++ 应用程序。

我有一个类变量，多个线程正在写入该变量。

在 C++ 中，任何可以在编译器“意识到”正在更改的情况下进行修改的内容都需要标记为易失性，对吗？因此，如果我的代码是多线程的，并且一个线程可能写入 var，而另一个线程从中读取，我是否需要标记 var volaltile？

[我没有竞争条件，因为我依赖对整数的写入是原子的]

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

大姐，你呐 2024-08-30 14:31:21

C++ 还没有任何多线程的规定。在实践中，易失性并没有按照你的意思做（它是为内存寻址硬件设计的，虽然这两个问题很相似，但它们的不同之处足以使易失性不能做正确的事情——请注意，易失性已被用于其他在 mt 上下文中使用的语言）。

因此，如果您想在一个线程中写入对象并在另一个线程中读取它，则必须在需要时使用实现所需的同步功能。据我所知，挥发性在其中不起任何作用。

仅供参考，下一个标准将考虑 MT，而 volatility 不会在其中发挥作用。所以这不会改变。您将只拥有需要同步的标准定义条件以及实现这些条件的标准定义方法。

回复收藏 0 原文

神回复 2024-08-30 14:31:21

是的，挥发性是您所需要的绝对最低限度。它确保代码生成器不会生成将变量存储在寄存器中的代码，并且始终执行对内存的读取和写入。大多数代码生成器可以为与本机 CPU 字大小相同的变量提供原子性保证，它们将确保内存地址对齐，以便变量不能跨越缓存行边界。

然而，对于现代多核 CPU 来说，这并不是一个非常强有力的契约。 Volatile 不承诺在另一个核心上运行的另一个线程可以看到变量的更新。这需要内存屏障，通常是刷新 CPU 缓存的指令。如果不提供屏障，线程实际上将继续运行，直到自然发生这种刷新。这最终会发生，线程调度程序必然会提供一个。这可能需要几毫秒。

一旦处理完这样的细节，您最终将重新发明一个条件变量（也称为事件），它不可能比线程库提供的条件变量更快。或者也经过测试。不要发明你自己的，线程很难做到正确，你不需要担心不确定最基本的原语是否可靠。

回复收藏 0 原文

标点 2024-08-30 14:31:21

易失性指示编译器不要根据变量值或用法的“直觉”进行优化，因为它可以“从外部”进行优化。

然而 volatile 不会提供任何同步，并且您对 int 的写入是原子的假设几乎是现实的！

我想我们需要查看一些用法来了解您的情况是否需要 volatile （或检查程序的行为）或更重要的是您是否看到某种同步。

回复收藏 0 原文

硬不硬你别怂 2024-08-30 14:31:21

我认为易失性仅适用于读取，尤其是读取内存映射的 I/O 寄存器。

它可用于告诉编译器不要假设一旦从内存位置读取该值就不会更改：

while (*p)
{
  // ...
}

在上面的代码中，如果 *p 未在循环内写入，编译器可能决定将读取移到循环之外，更像是这样：

cached_p=*p
while (cached_p)
{
  // ...
}

如果 p 是指向内存映射 I/O 端口的指针，则您需要检查端口的第一个版本每次进入循环之前。

如果 p 是多线程应用程序中指向内存的指针，您仍然不能保证写入是原子的。

I think that volatile only really applies to reading, especially reading memory-mapped I/O registers.

It can be used to tell the compiler to not assume that once it has read from a memory location that the value won't change:

while (*p)
{
  // ...
}

In the above code, if *p is not written to within the loop, the compiler might decide to move the read outside the loop, more like this:

cached_p=*p
while (cached_p)
{
  // ...
}

If p is a pointer to a memory-mapped I/O port, you would want the first version where the port is checked before the loop is entered every time.

If p is a pointer to memory in a multi-threaded app, you're still not guaranteed that writes are atomic.

回复收藏 0 原文

爱情眠于流年 2024-08-30 14:31:21

如果没有锁定，您仍然可能会得到编译器或处理器“不可能”的重新排序。并且不能保证对整数的写入是原子的。

最好使用适当的锁定。

回复收藏 0 原文

梓梦 2024-08-30 14:31:21

挥发性将解决你的问题，即。它将保证系统所有缓存之间的一致性。然而，它的效率很低，因为它会为每次 R 或 W 访问更新内存中的变量。您可能会考虑仅在需要时才使用内存屏障。
如果您正在使用 gcc/icc，请查看同步内置插件： http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html

编辑（主要是关于 pm100 评论）：
我知道我的信念不是参考，所以我找到了一些可以引用的东西:)

设计 volatile 关键字是为了防止编译器优化，在存在某些异步事件的情况下可能会导致代码不正确。例如， 如果您将原始变量声明为易失性，则不允许编译器将其缓存在寄存器中

来自 Dobb 博士的

更有趣：

易失性字段是可线性化的。读取易失性字段就像获取锁；工作存储器无效，并且从存储器中重新读取易失性字段的当前值。写入易失性字段就像释放锁：易失性字段会立即写回内存。
（这完全是关于一致性，而不是关于原子性）

来自多处理器编程的艺术，Maurice Herlihy & Nir Shavit

Lock 包含内存同步代码，如果你不加锁，你必须做一些事情，而使用 volatile 关键字可能是你能做的最简单的事情（即使它是为内存绑定到地址空间的外部设备设计的，但它不是重点在这里）