一叶扁舟

摘要： 不要在对时间敏感的上下文中使用 .get() 先看下面的代码， #include "stdafx.h" #include <future> #include <iostream> int main() { std::future<int> myFuture = std::async(std::lau 阅读全文

摘要： 前提： C++ 11 中提供了多线程的标准库，提供了管理线程、保护共享数据、线程间同步操作、原子操作等类。多线程库对应的头文件是 #include <thread>，类名为 std::thread。 然而线程毕竟是比较贴近系统的东西，使用起来仍然不是很方便，特别是线程同步及获取线程运行结果上就更加麻 阅读全文

摘要： 线程中的异常可以使用 std::rethrow_exception 抛给主线程 问题分析：一个线程中抛出的异常是没法被另一个线程捕获的。假如我们在主线程中创建一个子线程，子线程中的函数抛出了异常，主线程的 catch 是不会触发，如下， #include<iostream> #include<thr 阅读全文

摘要： 有时候使用 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 阅读全文