在哪些情况下我需要锁定一个变量以防止同时访问？答案

【问题标题】：in which cases do I need to lock a variable from simultaneous access?在哪些情况下我需要锁定一个变量以防止同时访问？
【发布时间】：2013-08-02 12:24:37
【问题描述】：

在 C 或 C++ 程序中，如果 2 个线程使用同一个全局变量，则需要通过互斥锁锁定 var。

但具体在哪些情况下呢？

线程 1：读取线程 2：读取
线程 1：写入线程 2：读取
线程 1：写入线程 2：写入

当然，您需要锁定案例 3，但其他 2 个案例是什么？案例 2（非原子操作）会发生什么？是否存在某种访问冲突或线程 2 是否只是获得旧值？我对此有点困惑，因为不能同时访问硬件级别的内存和寄存器（在普通 PC 硬件中）或者我们是否有某种并行 CPU 具有并行总线线路到并行 ram 芯片？

【问题讨论】：

情况 2 和 3，即至少一个线程正在写入并且至少一个其他线程正在读取或写入的任何情况。
从不同线程访问数据时并不总是需要加锁。查看原子操作，尤其是 C++11 的 std::atomic
是的，为了解决您的最后一句话，在多核 CPU 上，各个级别的缓存中的每个值都可以有多个副本。
（内核之间可能共享也可能不共享）
另外，请注意，在一个硬件上完全适合一个寄存器并且可以在一个 CPU 周期内完成对它的操作的东西，在另一个硬件上可能很容易需要多个周期。

标签： c++ c multithreading

【解决方案1】：

想想每种情况下可能会发生什么。让我们只考虑竞态条件：它很容易，足以让我们看到后果。

在情况 1 中，变量没有被修改，所以无论哪个顺序，两个线程都会读取相同的值。所以基本上，这里没有错。

情况 2 和 3 更糟。假设您有一个竞争条件，并且不知道哪些线程将更早获得访问权限。这意味着：

对于情况2：所有操作结束后变量的值没问题（会是线程1写入的值），但是线程2可能会得到变量的旧值，这可能会导致崩溃，或其他问题。

对于情况 3：变量的最终值是不可预测的，因为它取决于哪个线程将最后执行写操作。

对于情况 2 和 3，也可能会发生其中一个线程在变量处于不一致状态时尝试访问该变量，并且您最终可能会得到其中一个线程读取的一些垃圾数据（即 Case 2），甚至在完成所有操作后变量中的垃圾数据。

所以是的，锁定案例 2 和 3。

【讨论】：

情况 2 可能非常糟糕：当线程 2 读取变量时，该变量可能处于不一致状态。
@juanchopanza，是的，这是真的（对于案例 3 也是如此），但我没有提到它，以免使答案过于复杂。那么我应该将它添加到答案中，还是保持原样？
我认为有必要将此添加到答案中，这是非原子操作的主要问题。您的回答似乎暗示了原子性。另外，请注意，锁定不会保证任何特定的访问顺序。
线程是否实际上同时访问变量并不重要。规则是，如果另一个线程可能在某个时候修改了变量，那么读取线程必须使用某种同步指令（锁）。根据定义，如果没有同步指令，就会出现竞争条件。即使 CPU 同时没有访问权限，如果没有同步指令，也无法保证您看到其他线程写入的任何值。
这个答案不正确，或者至少具有误导性。情况 2 是未定义的行为。这不仅仅是获得陈旧价值的问题，任何事情都可能发生。

【解决方案2】：

锁定规则很简单：

如果您写入一个变量，同时被另一个线程访问，那么您需要正确的操作顺序（例如，通过锁定）。

通过这个简单的规则，我们可以轻松地评估每个案例：

无需写入，无需同步
写入，并发访问，需要同步
写入，并发访问，需要同步

如果你不锁定会发生什么？

嗯，正式地说，这是未定义的行为。意思是我们不知道。虽然唯一可能的回应确实有助于把握问题的严重程度。

在机器级别，可能发生的情况是：

在读取的情况下：访问过时的值
在读取的情况下：访问部分值（在您查看时仅更新一半）
在写入的情况下：最终值是值的大杂烩（在位级别）

...不要忘记，每当您读取不正确的指针/大小时，都可能导致崩溃。

在编译器级别，编译器可以优化就像线程具有唯一访问权限。在这种情况下，它可能意味着：

删除“冗余”读取：将while (flag) 转换为if (flag) while (true)...
删除“未使用”的写入
...

内存栅栏的存在和显式同步指令（互斥体的使用引入）阻止了这些优化。

【讨论】：

【解决方案3】：

规则很简单：如果一个对象被访问（读或写）多个线程，并且被任何线程修改，然后全部访问需要同步。否则，您有未定义的行为。

【讨论】：

【解决方案4】：

它并不像看起来那么简单，除了两种情况：

当只有读取器而没有写入器时，您永远不需要同步。
当有多个线程写入并且其中至少一个正在执行读取-修改-写入操作（例如++x;）时，您总是需要同步，否则您将完全不可预知的结果。

在所有其他情况下，如果您有至少一个写入者和一个读取器（或多个写入器），您通常（极少数例外）需要同步访问，但不一定总是，也不一定总是以最严格的方式。

这在很大程度上取决于您需要什么保证。一些应用程序需要严格的线程顺序一致性（有时您甚至需要锁公平性）。如果某些应用程序在同一个线程中仅具有发生前发生的保证，它们将同样运行良好，但性能要好得多。然而其他应用程序甚至不需要那么多，并且对轻松的操作或根本没有任何保证完全满意。

例如，工作线程的这种“典型”实现有一个写入器和一个读取器：

// worker thread
running = true;
while(running) { task = pull_task(); execute(task); }

// main thread exit code
running = false;
join(workerthread);

无需任何同步即可完美运行。是的，从迂腐的角度来说，running 的值何时或如何变化是未定义的，但实际上它没有任何区别。内存位置不可能有一些“随机”的中间值，并且更改是否在几十纳秒之前或之后变得可见并不重要，因为工作线程很可能无论如何都忙于执行任务，并且在最坏的情况下，它会在几毫秒后获取更改。最终，在下一次迭代中，工作线程将获取更改并退出。
几年前 Dobb 博士发表的 SPSC 快进队列的工作原理类似，只是使用了指针。

在GCC documentation 中提供了有关许多不同同步模式及其含义的全面阅读。

【讨论】：