一叶扁舟

摘要： 有时候使用 std::atomic 比使用 mutexes 更高效 问题分析：使用多线程更新一些简单数据时，比如 int 型，bool 型等等，可以使用 std::atomic，这比 mutex 来得更为高效。 比如，我们一般这样用： int counter; .... mu.lock(); cou 阅读全文

摘要： 不要重复获取同一个锁 问题：在获得一个锁并且没有释放该锁的前提下，再次尝试获取该锁会报错。 比如， #include <iostream> #include <thread> #include <mutex> std::mutex mu; static int counter = 0; void S 阅读全文

摘要： 要以相同顺序获取多个锁 多线程在加锁解锁时，可能会出现死锁问题，比如， 线程 1 在加锁 mutex A 后，继续尝试获取 mutex B，而 mutex B 已经被线程 2 获取，而线程 2 在等待获取 mutex A，mutex B 只有线程 2 获取 mutex A 后才能解锁， 这就导致线程 阅读全文

摘要： 加锁的临界区要尽可能的紧凑和小型 问题分析： 当一个线程在临界区内执行时，所有其他试图进入临界区的线程都会被阻止，所以我们应该保证临界区尽可能的小。比如， void CallHome(string message) { std::lock_guard<std::mutex> lock(mu); // 阅读全文

摘要： 发现问题的经过： 公司开发的 windows 程序在启动运行时，在右下角的托盘里右键程序图标退出后，在重新启动程序后，因为防多次启动机制（锁原理），会提示该程序已经在运行中 但是托盘里已经找不到程序的图标，并且任务管理器的进程选项卡也无法找到，最终在任务管理器的详细信息选项卡中找到了该进程，强制结束 阅读全文

摘要： 要记得对加锁的临界区解锁 前提：在多个线程共享一块资源或者数据时，我们需要加上互斥锁来保护临界区（否则出现数据未定义的行为） 问题：我们往往在写了很多代码之后忘记 unlock 互斥锁，那么等待该资源的所有其他线程将被无限期地阻塞，程序可能会挂起 解决方法：使用 RAII 类型的 std::lock 阅读全文

摘要： 对共享的资源或者数据做加锁处理 在多线程的环境下，有时需要多个线程对同一个资源或者数据进行操作，如果没有加锁，容易出现未定义的行为。 比如： #include <iostream> #include <string> #include <thread> #include <mutex> using 阅读全文

摘要： 传递给 C++ 线程的构造函数的参数是通过值传递的 VS 平台：2019 问题：如何在线程中改变传递的参数值？ 比如： #include <functional> #include <iostream> #include <string> #include <thread> void ChangeC 阅读全文

摘要： 试图 join 一个已经 detach 的线程 如果你已经在某个地方分离了线程，那你不可以在主线程再次 join，这是一个明显的错误 比如： #include <iostream> #include <thread> using namespace std; void LaunchRocket() 阅读全文

摘要： 在终止程序之前没有使用 join() 等待后台线程 前提分析：线程分为 joinable 状态和 detached 状态 添加 .join() 这句代码的时候，就表示主线程需要等待子线程运行结束回收掉子线程的资源后，再往下运行，否则就会产生一种情况：当子线程还没有运行完主线程先运行完了，那么就会结束 阅读全文