1. 修改第三章，线程存储期的内容。修改措辞，进行一些补充，强调 MSVC 的 std::async 存在的问题

2. 新建一节 CPU 变量，与全局变量、线程变量一起总结，阐述其在多线程并发中的作用与不同（创建标题）
3. 修改第五章，基本完成 `std::atomic<shared_ptr>` 的所有内容 Mq-b#12

Author: Mq-b

md/03共享数据.md

@@ -900,7 +900,7 @@ C++ 只保证了 `operator new`、`operator delete` 这两个方面的线程安
 
 ## 线程存储期
 
-**线程存储期**（也有人喜欢称作“[*线程局部存储*](https://zh.wikipedia.org/wiki/%E7%BA%BF%E7%A8%8B%E5%B1%80%E9%83%A8%E5%AD%98%E5%82%A8)”）的概念源自操作系统，是一种非常古老的机制，广泛应用于各种编程语言。线程存储期的对象在线程开始时分配，并在线程结束时释放。每个线程拥有自己独立的对象实例，互不干扰。在 C++11中，引入了[**`thread_local`**](https://zh.cppreference.com/w/cpp/keyword/thread_local)关键字，用于声明具有线程存储期的对象。
+**线程存储期**（也有人喜欢称作“[*线程局部存储*](https://zh.wikipedia.org/wiki/%E7%BA%BF%E7%A8%8B%E5%B1%80%E9%83%A8%E5%AD%98%E5%82%A8)”）的概念源自操作系统，是一种非常古老的机制，广泛应用于各种编程语言。线程存储期的对象在线程开始时分配，并在线程结束时释放。每个线程拥有自己独立的对象实例，互不干扰。在 C++11中，引入了[**`thread_local`**](https://zh.cppreference.com/w/cpp/keyword/thread_local)关键字，用于声明具有线程存储期的对象。不少开发者喜欢直接将声明为线程存储期的对象称为：**线程变量**；也与**全局变量**、**CPU 变量**，在一起讨论。
 
 以下是一段示例代码，展示了 `thread_local` 关键字的使用：
 
@@ -955,6 +955,44 @@ MSVC 无法使用 GCC 的编译器扩展，GCC 也肯定无法使用 MSVC 的扩
 
 了解其它 API 以及编译器扩展有助于理解历史上线程存储期的演进。同时扩展知识面。
 
+> ### 注意事项
+>
+> 需要注意的是，在 MSVC 的实现中，`std::async` 策略为 [`launch::async`](https://zh.cppreference.com/w/cpp/thread/launch) 并不是每次都创建一个新的线程，而是从线程池获取线程。**这意味着无法保证线程局部变量在任务完成时会被销毁**。如果线程被回收并用于新的 `std::async` 调用，则旧的线程局部变量仍然存在。因此，**建议不要将线程局部变量与 `std::async` 一起使用**。[文档](https://learn.microsoft.com/zh-cn/cpp/standard-library/future-functions?view=msvc-170)。
+>
+> 虽然还没有讲 `std::async` ，不过还是可以注意一下这个问题，我们用一个简单的示例为你展示：
+>
+> ```cpp
+> int n = 0;
+> 
+> struct X {
+>  ~X() { ++n; }
+> };
+> 
+> thread_local X x{};
+> 
+> void use_thread_local_x() {
+>  // 如果不写此弃值表达式，那么在 Gcc 与 Clang 编译此代码，会优化掉 x
+>  (void)x;
+> }
+> 
+> int main() {
+>  std::cout << "使用 std::thread: \n";
+>  std::thread{ use_thread_local_x }.join();
+>  std::cout << n << '\n';
+> 
+>  std::cout << "使用 std::async: \n";
+>  std::async(std::launch::async, use_thread_local_x);
+>  std::cout << n << '\n';
+> }
+> ```
+>
+> 在不同编译器上的输出结果：
+>
+> - **Linux/Windows GCC、Clang**：会输出 `1`、`2`，因为线程变量 `x` 在每个任务中被正确销毁析构。
+> - **Windows MSVC**：会输出 `1`、`1`，因为线程被线程池复用，线程依然活跃，线程变量 x 也还未释放。
+
+## CPU 变量
+
 ## 总结
 
 本章讨论了多线程的共享数据引发的恶性条件竞争会带来的问题。并说明了可以使用互斥量（`std::mutex`）保护共享数据，并且要注意互斥量上锁的“**粒度**”。C++标准库提供了很多工具，包括管理互斥量的管理类（`std::lock_guard`），但是互斥量只能解决它能解决的问题，并且它有自己的问题（**死锁**）。同时我们讲述了一些避免死锁的方法和技术。还讲了一下互斥量所有权转移。然后讨论了面对不同情况保护共享数据的不同方式，使用 `std::call_once()` 保护共享数据的初始化过程，使用读写锁（`std::shared_mutex`）保护不常更新的数据结构。以及特殊情况可能用到的互斥量 `recursive_mutex`，有些人可能喜欢称作：**递归锁**。最后聊了一下 `new`、`delete` 运算符的库函数实际是线程安全的，以及线程存储期。

md/05内存模型与原子操作.md

@@ -478,11 +478,41 @@ int main(){
 
 2. 任一线程使用 shared_ptr 的**非 const** 成员函数
 
----
+使用 `std::atomic<shared_ptr>` 修改：
+
+```cpp
+std::atomic<std::shared_ptr<Data>> data = std::make_shared<Data>();
+
+void writer() {
+    for (int i = 0; i < 10; ++i) {
+        std::shared_ptr<Data> new_data = std::make_shared<Data>(i);
+        data.store(new_data); // 原子地替换所保有的值
+        std::this_thread::sleep_for(10ms);
+    }
+}
+
+void reader() {
+    for (int i = 0; i < 10; ++i) {
+        if (data.load()) {
+            std::cout << "读取线程值: " << data.load()->get_value() << std::endl;
+        }
+        else {
+            std::cout << "没有读取到数据" << std::endl;
+        }
+        std::this_thread::sleep_for(10ms);
+    }
+}
+```
+
+很显然，这是线程安全的，`store` 是原子操作，而 `data.load()->get_value()` 只是个读取操作。
 
-不过事实上 `std::atomic<std::shared_ptr>` 的功能相当有限，单看它提供的修改接口（`=`、`store`、`load`、`exchang`）就能明白。如果要操作其保护的共享指针指向的资源还是得  `load()` 获取底层共享指针的副本。
+我知道，你肯定会想着：*能不能调用 `load()` 成员函数原子地返回底层的 `std::shared_ptr` 再调用 `swap` 成员函数？*
 
+可以，但是**没有意义**，因为 `load()` 成员函数返回的是底层 `std::shared_ptr` 的**副本**，也就是一个临时对象。对这个临时对象调用 `swap` 并不会改变 `data` 本身的值，因此这种操作没有实际意义，尽管这不会引发数据竞争（因为是副本）。
 
+由于我们没有对读写操作进行同步，只是确保了操作的线程安全，所以多次运行时可能会看到一些无序的打印，这是正常的。
+
+不过事实上 `std::atomic<std::shared_ptr>` 的功能相当有限，单看它提供的修改接口（`=`、`store`、`load`、`exchang`）就能明白。如果要操作其保护的共享指针指向的资源还是得  `load()` 获取底层共享指针的副本。此时再进行操作时就得考虑 `std::shared_ptr` 本身在多线程的支持了。
 
 ---
 
@@ -501,7 +531,7 @@ std::atomic<std::shared_ptr<int>> ptr = std::make_shared<int>(10);
 2. 解引用，等价 `*get()`，返回了 `int&`
 3. 直接修改这个引用所指向的资源。
 
-在第一步时，已经脱离了 `std::atomic` 的保护，第二步就获取了被保护的数据的引用，第三步进行了修改，这导致了数据竞争。当然了，这是做法非常的愚蠢，只是为了表示，所谓的线程安全，也是要靠**开发者的正确使用**。
+在第一步时，已经脱离了 `std::atomic` 的保护，第二步就获取了被保护的数据的引用，第三步进行了修改，这导致了数据竞争。当然了，这种做法非常的愚蠢，只是为了表示，所谓的线程安全，也是要靠**开发者的正确使用**。
 
 正确的用法如下：
 
@@ -512,6 +542,37 @@ ptr.store(std::make_shared<int>(100));
 
 通过使用 `store` 成员函数，可以原子地替换 `ptr` 所保护的值。
 
+---
+
+最后再来稍微聊一聊提供的 `wait`、`notify_one` 、`notify_all` 成员函数。这并非是 `std::atomic<shared_ptr>` 专属，C++20 以后任何 atomic 的特化都拥有这些成员函数，使用起来也都十分的简单，我们这里用一个简单的例子为你展示一下：
+
+```cpp
+std::atomic<std::shared_ptr<int>> ptr = std::make_shared<int>();
+
+void wait_for_wake_up(){
+    std::osyncstream{ std::cout }
+        << "线程 "
+        << std::this_thread::get_id()
+        << " 阻塞，等待更新唤醒\n";
+
+    // 等待 ptr 变为其它值
+    ptr.wait(ptr.load());
+
+    std::osyncstream{ std::cout }
+        << "线程 "
+        << std::this_thread::get_id()
+        << " 已被唤醒\n";
+}
+
+void wake_up(){
+    std::this_thread::sleep_for(5s);
+
+    // 更新值并唤醒
+    ptr.store(std::make_shared<int>(10));
+    ptr.notify_one();
+}
+```
+
 ## 内存次序
 
 ### 前言