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

2+ 的真正危险线程写入/读取变量

发布于 2024-11-05 18:03:34 字数 152 浏览 1 评论 0原文

同时读/写单个变量的真正危险是什么？

如果我使用一个线程写入变量，另一个线程在 while 循环中读取变量，并且在写入变量时读取变量并且使用旧值，则不会有危险，这里还有什么危险？

同时读/写是否会导致线程崩溃，或者当发生精确的同时读/写时，低级别会发生什么？

原文

分享到QQ

分享到微博

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

发布评论

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

末が日狂欢 2024-11-12 18:03:34

如果两个线程在没有适当同步的情况下访问变量，并且这些访问中至少有一个是写入，那么就会出现数据争用和未定义的行为。

未定义行为的表现方式完全取决于实现。在大多数现代体系结构中，您不会从硬件中获得陷阱或异常或任何内容，并且它将读取某些内容，或存储某些内容。问题是，它不一定会读取或写入您期望的内容。

例如，使用两个线程递增变量，您可能会错过计数，如我在 devx 上的文章中所述： http: //www.devx.com/cplus/Article/42725

对于单个作者和单个读者，最常见的结果是读者看到过时的值，但您也可能看到部分更新的值如果更新需要多个周期，或者变量跨缓存行拆分。然后会发生什么取决于你用它做什么——如果它是一个指针并且你得到了部分更新的值那么它可能不是一个有效的指针，并且无论如何也不会指向你想要的东西，然后你可能会由于取消引用无效的指针值而导致任何类型的损坏或错误。如果坏指针值恰好指向内存映射 I/O 寄存器，这可能包括格式化硬盘或其他不良后果......

回复收藏 0 原文

无言温柔 2024-11-12 18:03:34

一般来说，你会得到意想不到的结果。维基百科定义了两种不同的赛车条件：

当内部变量更改的顺序决定状态机最终所处的状态时，就会发生关键竞争。
当内部变量更改的顺序不会改变最终状态时，就会发生非关键竞争。换句话说，当移动到所需状态时发生非关键竞争意味着必须同时更改多个内部状态变量，但无论这些内部状态变量以什么顺序更改，结果状态都将是相同的。

所以输出不会总是混乱，这取决于代码。始终处理竞争条件是一种很好的做法，以便以后进行代码扩展并防止可能的错误。没有什么比无法信任自己的数据更烦人的了。

回复收藏 0 原文

弃爱 2024-11-12 18:03:34

两个线程读取相同的值完全没有问题。

当一个线程写入非原子变量而另一个线程读取它时，问题就开始了。那么读取的结果是未定义的。由于线程可能随时被抢占（停止）。只有对原子变量的操作才能保证不可破坏。原子操作通常是写入 int 类型变量。

如果有两个线程访问相同的数据，则最佳实践+通常不可避免地使用锁定（互斥体、信号量）。

马里奥

回复收藏 0 原文

溺渁∝ 2024-11-12 18:03:34

取决于平台。例如，在Win32上，对齐的32位值的读写操作是原子的——也就是说，你不能一半读一个新值，一半读一个旧值，如果你写，那么当有人来读时，要么获得完整的新值，要么获得旧值。当然，并非所有价值观或所有平台都是如此。

回复收藏 0 原文

心如荒岛 2024-11-12 18:03:34

结果未定义。

考虑这段代码：

global int counter = 0;


tread()
{
   for(i=0;i<10;i++)
   {
       counter=counter+1;
   }
}

问题是，如果有 N 个线程，结果可能是 10 到 N*10 之间的任何值。
这是因为可能会发生所有线程读取相同值的情况，增加该值，然后将值+1 写回。但你问是否可以使程序或硬件崩溃。
这取决于。大多数情况下错误的结果是无用的。

为了解决这个锁定问题，您需要互斥锁或信号量。

互斥体是代码的锁。在大写字母中，您将锁定行中的部分代码

counter = counter+1;

，其中信号量是变量的锁，

counter

解决相同类型的问题基本上是相同的事情。

在您的履带库中检查此工具。

http://en.wikipedia.org/wiki/Mutual_exclusion

Result is undefined.

Consider this code:

global int counter = 0;


tread()
{
   for(i=0;i<10;i++)
   {
       counter=counter+1;
   }
}

Problem is that if you have N threads result can be anything between 10 and N*10.
This is because it might happen all treads read same value increase it and then write value +1 back. But you asked if you can crash program or hardware.
It depends. In most cases are wrong results useless.

For solving this locking problem you need mutex or semaphore.

Mutex is lock for code. In upper case you would lock part of code in line

counter = counter+1;

Where semaphore is lock for variable

counter

Basicaly same thing for solving same type of problem.

Check for this tools in your tread library.

http://en.wikipedia.org/wiki/Mutual_exclusion

回复收藏 0 原文

岁月静好 2024-11-12 18:03:34

最坏的情况取决于实施情况。 pthreads 有如此多完全独立的实现，运行在不同的系统和硬件上，我怀疑有人知道它们的一切。

如果p不是指向易失性的指针，那么我认为符合Posix实现的编译器允许转变

while (*p == 0) {}
exit(0);

为：*的单一检查p 后面跟着一个无限循环，根本不关心 *p 的值。实际上，它不会，所以问题是您是否要按照标准进行编程，还是要按照您正在使用的实现的未记录的观察到的行为进行编程。后者通常适用于简单的情况，然后您可以在代码上进行构建，直到您执行的操作足够复杂以至于意外无法正常工作。

实际上，在没有一致内存缓存的多 CPU 系统上，while 循环可能需要很长时间才能看到来自不同 CPU 的更改，因为如果没有内存屏障，它可能永远不会更新其缓存视图主存储器。但英特尔拥有一致的缓存，因此您个人很可能不会看到任何足够长的延迟而无需担心。如果一些可怜的傻瓜试图在更奇特的架构上运行您的代码，他们最终可能不得不修复它。

回到理论，您所描述的设置可能会导致崩溃。想象一个假设的架构，其中：

p 指向非原子类型，例如典型 32 位架构上的 long long。
该系统上的long long具有陷阱表示，例如因为它有一个用作奇偶校验的填充位。
当读取发生时，对*p的写入是半完成的，
半写入已经更新了值的一些位，但尚未更新奇偶校验位。

Bang，未定义的行为，你读到了一个陷阱表示。 Posix 可能禁止 C 标准允许的某些陷阱表示，在这种情况下，long long 可能不是 *p 类型的有效示例，但我希望您可以找到允许陷阱表示的类型。

The worst that will happen depends on the implementation. There are so many completely independent implementations of pthreads, running on different systems and hardware, that I doubt anyone knows everything about all of them.

If p isn't a pointer-to-volatile then I think that a compiler for a conforming Posix implementation is allowed to turn:

while (*p == 0) {}
exit(0);

Into a single check of *p followed by an infinite loop that doesn't bother looking at the value of *p at all. In practice, it won't, so it's a question of whether you want to program to the standard, or program to undocumented observed behavior of the implementations you're using. The latter generally works for simple cases, and then you build on the code until you do something complicated enough that it unexpectedly doesn't work.

In practice, on a multi-CPU system that doesn't have coherent memory caches, it could be a very long time before that while loop ever sees a change made from a different CPU, because without memory barriers it might never update its cached view of main memory. But Intel has coherent caches, so most likely you personally won't see any delays long enough to care about. If some poor sucker ever tries to run your code on a more exotic architecture, they may end up having to fix it.

Back to theory, the setup you're describing could cause a crash. Imagine a hypothetical architecture where:

p points to a non-atomic type, like long long on a typical 32 bit architecture.
long long on that system has trap representations, for example because it has a padding bit used as a parity check.
the write to *p is half-complete when the read occurs
the half-write has updated some of the bits of the value, but has not yet updated the parity bit.

Bang, undefined behavior, you read a trap representation. It may be that Posix forbids certain trap representations that the C standard allows, in which case long long might not be a valid example for the type of *p, but I expect you can find a type for which trap representations are permitted.

回复收藏 0 原文