我需要用锁保护这个变量吗？ [英] Do I need to protect this variable with a lock?

问题描述

所以我在多处理器机器上有一个布尔类型的C ++。变量开始的生命为真，然后有几个线程，其中任何一个或多个可能写为假。

同时，这些线程也可以读取此变量以检查其状态。我不在乎如果读取这个变量与任何写入同步，它们都发生在代码中的不同位置，并且无论它在任何特定写入之前还是之后都无关紧要。现在，我需要为这个布尔值锁吗？

我需要一个锁的唯一方法是如果在非常低的水平，内存可以被两个竞争写。例如，如果处理器A上的汇编指令正在将0写入代表布尔值的字节，同时处理器B正在进行相同...而不是写入0，则存储器结束为值22或东西。这可能会混乱的东西。

所以，一般来说，如果proc A正在写一个内存位置3，而proc B正在写7，没有同步，我保证至少3或7？

编辑：

感谢评论家们。一些更多的信息：当然有程序中的同步。总而言之，所讨论的标志是告诉某个存储器池是否是脏的（需要被压缩）。任何线程因此可以决定将此标志设置为false（意味着池是脏的）。例如，从池中释放内存使其变脏。然后任何线程都可以读取这个标志，并设置另一个标志来表示需要清理 - 这个检查是在从池中分配内存时完成的，如果内存不足，则会发出清除信号。在我的主关键部分在迭代之间，每个线程去寻找更多的数据进程，我将有线程检查这第二个标志，并做一些适当的，以确保：所有其他的完成他们的当前迭代，一个线程清除内存，将第一个标志设置为true（因为池不脏），将第二个标志设置为false，然后再次释放所有线程。

所以我不认为我需要一个锁，因为：锁将确保写不会发生在与另一个写或读的同时。但是谁在乎，只要硬件不会失败我，最坏的情况是，读取在写入之前或之后随机发生 - 这是同样的事情，如果我用锁保护它，

我认为相同的参数适用于我提到的第二个标志。

解决方案

如果只是检查变量的状态，并将其设置为false，很多担心，除了一些线程可能有点晚，看到变量已经设置为false。 （这可以在某种程度上通过使用volatile关键字来克服。）然后两个线程可以将其设置为false，这是没有问题的，因为变量在一个方向上设置为单个值。让我们说布尔写入内存位置不能保证是原子的，有什么危害？

仍然，如果出现以下情况，您必须使用锁定方法：

• 值设置不只是单向：您将其设置为false，然后返回true，然后再次为false等。


• 一些依赖操作对信息的线程已将值设置为false。因为显然可能有两个获胜者。

so I have a boolean type in C++ on a multiprocessor machine. The variable starts out life as true, and then there are a few threads, any one or more of which might write it to be false.

At the same time, these threads may also read this variable to check its state. I don't care if reading this variable is synchronized with any of the writes, they each happen at different places in the code, and it doesn't matter if it comes before or after any particular write. Now, do I need a lock for this boolean?

The only way I would need a lock is if at the very low level, memory can get corrupted by two competing writes. If, for example, an assembly instruction on processor A is writing 0 to the byte that represents the boolean at the same time as processor B is doing the same... and instead of having written 0, the memory ends up with value 22 or something. That could mess something up.

So, generally, if proc A is writing 3 to a memory location, while proc B is writing 7, with no synchronization, am I guaranteed to end up with at least either 3 or 7? Or is it that easy to break memory?

Edit:

Thanks for the comments guys. Some more info: There is synchronization in the program of course. To summarize, the flag in question is telling if a certain memory pool is "dirty" (needs to be compacted). Any thread can hence decide to set this flag to false (meaning pool is dirty). For example, freeing memory from the pool makes it dirty. Any thread can then also read this flag and set another flag to signal that a clean-up is needed -- this check is done when memory is allocated from the pool, the clean-up is signaled if we're low on memory. Somewhere in my master critical section between iterations, where each thread goes to look for more data to process, I will have the threads check this second flag, and do something appropriate to make sure that: all other theads finish their current iteration, one thread cleans up the memory, sets the first flag back to true (as in pool is not dirty), sets the second flag back to false, and then releases all the threads again.

So I don't think I need a lock because: a lock would ensure that a write doesn't happen at the same time as another write or a read. But who cares, as long as the hardware doesn't fail me, the worst-case-scenario is that the read happens randomly before or after the write -- this is the same thing that would happen if I protected it with a lock, just then we'd really be sure it came before or after...

I think the same argument applies to the second flag I mentioned above.

解决方案

If only you're checking the state of the variable and setting it to false in one direction ever, there's not much to worry about except that some of the threads may be a little late to see the variable is already set to false. (this may be overcome to some degree by the use of 'volatile' keyword.) Then two threads may set it to false, which is no problem since the variable is set to a single value in one direction. Let's say boolean write to the memory location is not guaranteed to be atomic, what's the harm? The final value they both will write is the same.

Still, you would have to use a method of locking if:

• Value setting is not one-direction only: you set it to false, then back to true, then false again, etc.
• You take some dependent action on the information which thread had set the value to false. Because there obviously may be two winners.

这篇关于我需要用锁保护这个变量吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！