fut and pro

Author: howardlau1999

docs/parallel/multi-threading.md

@@ -271,7 +271,7 @@ terminate called without an active exception
 
 而使用互斥量的时候，则是直接对数据结构加锁，同时只有一个线程在修改数据，修改完了再解锁，允许下一个线程进入临界区，等于将线程排队。这是一种悲观的（Pessimistic）方法，因为它认为发生冲突的概率大于不冲突的概率。
 
-原子量和互斥量各有优劣，原子量缩小了临界区，增大了并发度，但是在冲突较多的时候需要大量地回退和重试，而且不好写。互斥量的临界区较大，并发度低，但是理解起来比较容易，也不需要回退和重试。
+原子量和互斥量各有优劣，原子量缩小了临界区，增大了并发度，但是在冲突较多的时候需要大量地回退和重试，而且不好写。互斥量的临界区较大，并发度低，在使用不当的情况下可能出现死锁问题，但是理解起来比较容易，也不需要回退和重试。
 
 那么应该什么时候使用原子量，什么时候使用互斥量？从开发者的角度来讲，在项目开发的初期，推荐使用互斥量，因为它编写和理解起来都比较简单。而在项目稳定后，经过性能分析，确定了互斥量是性能瓶颈之后，再想办法修改为使用原子量的并发控制。而且，使用原子量编写一个数据结构很容易，但是编写一个**正确的**数据结构是一个非常困难的问题，需要严苛的测试甚至是严格的数学证明。在工程实践中，建议也是直接使用经过大量测试以及验证的成熟的数据结构库。
 
@@ -335,3 +335,6 @@ terminate called without an active exception
 由于各种原因，通过 `wait()` 而被阻塞的线程有可能会在条件变量并没有被调用 `notify()` 等函数时被唤醒，这种现象被称为 spurious wakeup。此时等待线程会拿锁，然后检查输入的函数的返回值，此时返回值一般为 `false`（因为此时确实没有新数据），然后再一次进入阻塞状态。在这个过程中没有发生数据竞争。
 
 条件变量的设计天然地防止了问题的产生。我们还可以尝试将 `producer()` 中的 `cv.notify_one()` 改为 `cv.notify_all()`，它会唤醒所有等待线程，但与此同时我们只输出了一个新数据。结果是：等待线程只会有一个拿到这个新数据，其他线程会再一次进入阻塞状态，仍然没有数据竞争的出现。
+
+???+note "轮询与等待队列"
+    在繁忙的程序中，队列可能几乎每时每刻都有数据产生，此时直接使用循环轮询，避免使用互斥量以及条件变量，可能会取得更高的性能，更加充分利用 CPU。

docs/parallel/practice/callback.md

@@ -0,0 +1,31 @@
+# 回调模型
+
+有时候我们希望开一个线程去执行一些耗时的操作，例如执行一个很复杂的计算，或者发送一个网络请求，并且想得到函数执行的结果。一种办法是使用一个回调函数接受结果。例如：
+
+```cpp
+#include <iostream>
+#include <chrono>
+#include <thread>
+#include <functional>
+
+int calculate(int arg) {
+    std::this_thread::sleep_for(std::chrono::seconds(1));
+    return arg + 42;
+}
+
+void do_work(int arg, std::function<void(int)> callback) {    
+    int result = calculate(arg);
+    callback(result);
+}
+
+int main() {
+    std::thread t(do_work, 1, [](int result) {
+        std::cout << result << std::endl;
+    });
+    std::cout << "Continue main" << std::endl;
+    t.join();
+    return 0;
+}
+```
+
+对于普通的函数，我们只需要用一个包装函数来负责将结果传递给回调函数，然后开启一个新的线程去调用这个包装函数即可。不过，回调函数容易陷入回调地狱中，当执行的操作一多起来的时候，就会产生非常深的回调嵌套。

docs/parallel/practice/promise.md

@@ -0,0 +1,44 @@
+# Promise 模式
+
+Promise 是“承诺”的意思，看上去并不是很好理解，它的作用是将一个值存放起来，并提供给另一个线程读取。举个例子：
+
+```cpp
+#include <iostream>
+#include <chrono>
+#include <thread>
+#include <functional>
+#include <future>
+
+int calculate(int arg) {
+    std::this_thread::sleep_for(std::chrono::seconds(1));
+    return arg + 42;
+}
+
+void do_work(int arg, std::promise<int> p) {    
+    int result = calculate(arg);
+    p.set_value(result);
+}
+
+int main() {
+    std::promise<int> p;
+    std::future<int> fut = p.get_future();
+    std::thread t(do_work, 1, std::move(p));
+    t.detach();
+    std::cout << "Continue main" << std::endl;
+    std::cout << fut.get() << std::endl;
+    return 0;
+}
+```
+
+可以看到，promise 的使用方法也不太直观，有点像[回调模式](callback.md)，但又不完全像，还需要通过一个 `future` 才能拿到返回值。`future` 又是什么？为什么不能直接从 `promise` 取值？通过文档可以看到，`future` 只有 `get_value()`，而 `promise` 只有 `set_value()` 操作。也就是说，给 `promise` 设置值之后，甚至不能直接从里面将值获取回来，而 `future` 只能通过其他类来设置值，作为使用者只能从中获取值。
+
+这种设计的逻辑是，通过类型来区分值的提供者和使用者，提供者不应该使用值而使用者不应该设置值，并通过 API 保证共享状态不会被错误地修改。
+
+而在没有设置值的时候，调用 `future` 的 `get()` 会阻塞并挂起线程，一旦有值则唤醒线程并返回值。可以理解为：
+
+```cpp
+cv.wait(lk, []() { state == READY });
+return value;
+```
+
+使用 Promise 可以避免回调地狱，用更自然地方法编写程序。

mkdocs.yml

@@ -109,6 +109,8 @@ nav:
     - 实战:
       - 多线程共享队列: "parallel/practice/multi-threading-queue.md"
       - 多进程共享队列: "parallel/practice/multi-processing-queue.md"
+      - 回调模型: "parallel/practice/callback.md"
+      - "Promise 模型": "parallel/practice/promise.md"
       - 线程池: "parallel/practice/thread-pool.md"
       - 进程池: "parallel/practice/process-pool.md"
   - 网络编程 RPC 入门: