EffectiveModernCppChinese/7.TheConcurrencyAPI/item39.html

329 lines
35 KiB
HTML
Raw Normal View History

<!DOCTYPE HTML>
<html lang="zh" class="sidebar-visible no-js light">
<head>
<!-- Book generated using mdBook -->
<meta charset="UTF-8">
<title>Item 39: Consider void futures for one-shot event communication - Effective Modern C++</title>
<!-- Custom HTML head -->
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#ffffff" />
<link rel="icon" href="../favicon.svg">
<link rel="shortcut icon" href="../favicon.png">
<link rel="stylesheet" href="../css/variables.css">
<link rel="stylesheet" href="../css/general.css">
<link rel="stylesheet" href="../css/chrome.css">
<link rel="stylesheet" href="../css/print.css" media="print">
<!-- Fonts -->
<link rel="stylesheet" href="../FontAwesome/css/font-awesome.css">
<link rel="stylesheet" href="../fonts/fonts.css">
<!-- Highlight.js Stylesheets -->
<link rel="stylesheet" href="../highlight.css">
<link rel="stylesheet" href="../tomorrow-night.css">
<link rel="stylesheet" href="../ayu-highlight.css">
<!-- Custom theme stylesheets -->
<!-- MathJax -->
<script async type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
</head>
<body>
<!-- Provide site root to javascript -->
<script type="text/javascript">
var path_to_root = "../";
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "navy" : "light";
</script>
<!-- Work around some values being stored in localStorage wrapped in quotes -->
<script type="text/javascript">
try {
var theme = localStorage.getItem('mdbook-theme');
var sidebar = localStorage.getItem('mdbook-sidebar');
if (theme.startsWith('"') && theme.endsWith('"')) {
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
}
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
}
} catch (e) { }
</script>
<!-- Set the theme before any content is loaded, prevents flash -->
<script type="text/javascript">
var theme;
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
if (theme === null || theme === undefined) { theme = default_theme; }
var html = document.querySelector('html');
html.classList.remove('no-js')
html.classList.remove('light')
html.classList.add(theme);
html.classList.add('js');
</script>
<!-- Hide / unhide sidebar before it is displayed -->
<script type="text/javascript">
var html = document.querySelector('html');
var sidebar = 'hidden';
if (document.body.clientWidth >= 1080) {
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
sidebar = sidebar || 'visible';
}
html.classList.remove('sidebar-visible');
html.classList.add("sidebar-" + sidebar);
</script>
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
<div class="sidebar-scrollbox">
<ol class="chapter"><li class="chapter-item expanded "><a href="../Introduction.html">Introduction</a></li><li class="chapter-item expanded "><div>Chapter 1. Deducing Types</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="../1.DeducingTypes/item1.html">Item 1: Understanding template type deduction</a></li><li class="chapter-item expanded "><a href="../1.DeducingTypes/item2.html">Item 2: Understand auto type deduction</a></li><li class="chapter-item expanded "><a href="../1.DeducingTypes/item3.html">Item 3: Understand decltype</a></li><li class="chapter-item expanded "><a href="../1.DeducingTypes/item4.html">Item 4: Know how to view deduced types</a></li></ol></li><li class="chapter-item expanded "><div>Chapter 2. auto</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="../2.Auto/item5.html">Item 5: Prefer auto to explicit type declarations</a></li><li class="chapter-item expanded "><a href="../2.Auto/item6.html">Item 6: Use the explicitly typed initializer idiom when auto deduces undesired types</a></li></ol></li><li class="chapter-item expanded "><div>Chapter 3. Moving to Modern C++</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item7.html">Item 7: Distinguish between () and {} when creating objects</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item8.html">Item 8: Prefer nullptr to 0 or NULL</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item9.html">Item 9: Prefer alias declarations to typedefs</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item10.html">Item 10: Prefer scoped enums to unscoped enums</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item11.html">Item 11: Prefer deleted functions to private undefined ones</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item12.html">Item 12: Declare overriding functions override</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item13.html">Item 13: Prefer const_iterators to iterators</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item14.html">Item 14: Declare functions noexcept if they won't emit exceptions</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item15.html">Item 15: Use constexpr whenever possible</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item16.html">Item 16: Make const member functions thread safe</a></li><li class="chapter-item expanded "><a href="../3.MovingToModernCpp/item17.html">Item 17: Understand special member funciton generation</a></li></ol></li><li class="chapter-item expanded "><div>Chapter 4. Smart Pointer</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="../4.SmartPointers/item18.html">Item 18: Use std::unique_ptr for exclusive-ownership resource management</a></li><li class="chapter-item expanded "><a href="../4.SmartPointers/item19.html">Item 19: Use std::shared_ptr for shared-ownership resource management</a></li><li class="chapter-item expanded "><a href="../4.SmartPointers/item20.html">Item 20: Use std::weak_ptr for std::shared_ptr like pointers that can dangle</a></li><li class="chapter-item expanded "><a href="../4.SmartPointers/item21.html">Item 21: Prefer std::make_unique and std::make_shared to direct use of new</a></li><li class="chapter-item expanded "><a href="../4.SmartPointers/item22.html">Item 22: When using the Pimpl Idiom, define special member functions in the implementation file</a></li></ol></li><li class="chapter-item expanded "><div>Chapter 5. Rvalue References, Move Semantics, and Perfect Forwarding</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="../5.RRefMovSemPerfForw/item23.html">Item 23: Understand std::move and std::forward</a></li><li class="chapter-item expanded "><a href="../5.RRefMovSemPerfForw/item24.html">Item 24: Distinguish universal references from rvalue references</a></li><li class
</div>
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
</nav>
<div id="page-wrapper" class="page-wrapper">
<div class="page">
<div id="menu-bar-hover-placeholder"></div>
<div id="menu-bar" class="menu-bar sticky bordered">
<div class="left-buttons">
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
<i class="fa fa-bars"></i>
</button>
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
<i class="fa fa-paint-brush"></i>
</button>
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
</ul>
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
<i class="fa fa-search"></i>
</button>
</div>
<h1 class="menu-title">Effective Modern C++</h1>
<div class="right-buttons">
<a href="../print.html" title="Print this book" aria-label="Print this book">
<i id="print-button" class="fa fa-print"></i>
</a>
</div>
</div>
<div id="search-wrapper" class="hidden">
<form id="searchbar-outer" class="searchbar-outer">
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
</form>
<div id="searchresults-outer" class="searchresults-outer hidden">
<div id="searchresults-header" class="searchresults-header"></div>
<ul id="searchresults">
</ul>
</div>
</div>
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
<script type="text/javascript">
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
});
</script>
<div id="content" class="content">
<main>
<h2 id="条款三十九对于一次性事件通信考虑使用void的futures"><a class="header" href="#条款三十九对于一次性事件通信考虑使用void的futures">条款三十九:对于一次性事件通信考虑使用<code>void</code><em>futures</em></a></h2>
<p><strong>Item 39: Consider <code>void</code> futures for one-shot event communication</strong></p>
<p>有时,一个任务通知另一个异步执行的任务发生了特定的事件很有用,因为第二个任务要等到这个事件发生之后才能继续执行。事件也许是一个数据结构已经初始化,也许是计算阶段已经完成,或者检测到重要的传感器值。这种情况下,线程间通信的最佳方案是什么?</p>
<p>一个明显的方案就是使用条件变量(<em>condition variable</em>,简称<em>condvar</em>)。如果我们将检测条件的任务称为<strong>检测任务</strong><em>detecting task</em>),对条件作出反应的任务称为<strong>反应任务</strong><em>reacting task</em>),策略很简单:反应任务等待一个条件变量,检测任务在事件发生时改变条件变量。代码如下:</p>
<pre><code class="language-cpp">std::condition_variable cv; //事件的条件变量
std::mutex m; //配合cv使用的mutex
</code></pre>
<p>检测任务中的代码不能再简单了:</p>
<pre><code class="language-cpp">… //检测事件
cv.notify_one(); //通知反应任务
</code></pre>
<p>如果有多个反应任务需要被通知,使用<code>notify_all</code>代替<code>notify_one</code>,但是这里,我们假定只有一个反应任务需要通知。</p>
<p>反应任务的代码稍微复杂一点,因为在对条件变量调用<code>wait</code>之前,必须通过<code>std::unique_lock</code>对象锁住互斥锁。(在等待条件变量前锁住互斥锁对线程库来说是经典操作。通过<code>std::unique_lock</code>锁住互斥锁的需要仅仅是C++11 API要求的一部分。概念上的代码如下</p>
<pre><code class="language-cpp">… //反应的准备工作
{ //开启关键部分
std::unique_lock&lt;std::mutex&gt; lk(m); //锁住互斥锁
cv.wait(lk); //等待通知,但是这是错的!
… //对事件进行反应m已经上锁
} //关闭关键部分通过lk的析构函数解锁m
… //继续反应动作m现在未上锁
</code></pre>
<p>这份代码的第一个问题就是有时被称为<strong>代码异味</strong><em>code smell</em>)的一种情况:即使代码正常工作,但是有些事情也不是很正确。在这个情况中,这种问题源自于使用互斥锁。互斥锁被用于保护共享数据的访问,但是可能检测任务和反应任务可能不会同时访问共享数据,比如说,检测任务会初始化一个全局数据结构,然后给反应任务用,如果检测任务在初始化之后不会再访问这个数据结构,而在检测任务表明数据结构准备完了之前反应任务不会访问这个数据结构,这两个任务在程序逻辑下互不干扰,也就没有必要使用互斥锁。但是条件变量的方法必须使用互斥锁,这就留下了令人不适的设计。</p>
<p>即使你忽略掉这个问题,还有两个问题需要注意:</p>
<ul>
<li>
<p><strong>如果在反应任务<code>wait</code>之前检测任务通知了条件变量,反应任务会挂起</strong>。为了能使条件变量唤醒另一个任务,任务必须等待在条件变量上。如果在反应任务<code>wait</code>之前检测任务就通知了条件变量,反应任务就会丢失这次通知,永远不被唤醒。</p>
</li>
<li>
<p><strong><code>wait</code>语句虚假唤醒</strong>。线程API的存在一个事实在许多语言中——不只是C++),等待一个条件变量的代码即使在条件变量没有被通知时,也可能被唤醒,这种唤醒被称为<strong>虚假唤醒</strong><em>spurious wakeups</em>。正确的代码通过确认要等待的条件确实已经发生来处理这种情况并将这个操作作为唤醒后的第一个操作。C++条件变量的API使得这种问题很容易解决因为允许把一个测试要等待的条件的<em>lambda</em>(或者其他函数对象)传给<code>wait</code>。因此,可以将反应任务<code>wait</code>调用这样写:</p>
<pre><code class="language-cpp">cv.wait(lk,
[]{ return whether the evet has occurred; });
</code></pre>
<p>要利用这个能力需要反应任务能够确定其等待的条件是否为真。但是我们考虑的场景中,它正在等待的条件是检测线程负责识别的事件的发生情况。反应线程可能无法确定等待的事件是否已发生。这就是为什么它在等待一个条件变量!</p>
</li>
</ul>
<p>在很多情况下,使用条件变量进行任务通信非常合适,但是也有不那么合适的情况。</p>
<p>对于很多开发者来说他们的下一个诀窍是共享的布尔型flag。flag被初始化为<code>false</code>。当检测线程识别到发生的事件将flag置位</p>
<pre><code class="language-cpp">std::atomic&lt;bool&gt; flag(false); //共享的flagstd::atomic见条款40
… //检测某个事件
flag = true; //告诉反应线程
</code></pre>
<p>就其本身而言反应线程轮询该flag。当发现flag被置位它就知道等待的事件已经发生了</p>
<pre><code class="language-cpp">… //准备作出反应
while (!flag); //等待事件
… //对事件作出反应
</code></pre>
<p>这种方法不存在基于条件变量的设计的缺点。不需要互斥锁在反应任务开始轮询之前检测任务就对flag置位也不会出现问题并且不会出现虚假唤醒。好好。</p>
<p>不好的一点是反应任务中轮询的开销。在任务等待flag被置位的时间里任务基本被阻塞了但是一直在运行。这样反应线程占用了可能能给另一个任务使用的硬件线程每次启动或者完成它的时间片都增加了上下文切换的开销并且保持核心一直在运行状态否则的话本来可以停下来省电。一个真正阻塞的任务不会发生上面的任何情况。这也是基于条件变量的优点因为<code>wait</code>调用中的任务真的阻塞住了。</p>
<p>将条件变量和flag的设计组合起来很常用。一个flag表示是否发生了感兴趣的事件但是通过互斥锁同步了对该flag的访问。因为互斥锁阻止并发访问该flag所以如<a href="https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/7.TheConcurrencyAPI/item40.md">Item40</a>所述不需要将flag设置为<code>std::atomic</code>。一个简单的<code>bool</code>类型就可以,检测任务代码如下:</p>
<pre><code class="language-cpp">std::condition_variable cv; //跟之前一样
std::mutex m;
bool flag(false); //不是std::atomic
… //检测某个事件
{
std::lock_guard&lt;std::mutex&gt; g(m); //通过g的构造函数锁住m
flag = true; //通知反应任务第1部分
} //通过g的析构函数解锁m
cv.notify_one(); //通知反应任务第2部分
</code></pre>
<p>反应任务代码如下:</p>
<pre><code class="language-cpp">… //准备作出反应
{ //跟之前一样
std::unique_lock&lt;std::mutex&gt; lk(m); //跟之前一样
cv.wait(lk, [] { return flag; }); //使用lambda来避免虚假唤醒
… //对事件作出反应m被锁定
}
… //继续反应动作m现在解锁
</code></pre>
<p>这份代码解决了我们一直讨论的问题。无论在检测线程对条件变量发出通知之前反应线程是否调用了<code>wait</code>都可以工作即使出现了虚假唤醒也可以工作而且不需要轮询。但是仍然有些古怪因为检测任务通过奇怪的方式与反应线程通信。译者注下面的话挺绕的可以参考原文检测任务通过通知条件变量告诉反应线程等待的事件可能发生了但是反应线程必须通过检查flag来确保事件发生了。检测线程置位flag来告诉反应线程事件确实发生了但是检测线程仍然还要先需要通知条件变量以唤醒反应线程来检查flag。这种方案是可以工作的但是不太优雅。</p>
<p>一个替代方案是让反应任务通过在检测任务设置的<em>future</em><code>wait</code>来避免使用条件变量互斥锁和flag。这可能听起来也是个古怪的方案。毕竟<a href="https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/7.TheConcurrencyAPI/item38.md">Item38</a>中说明了<em>future</em>代表了从被调用方到(通常是异步的)调用方的通信信道的接收端,这里的检测任务和反应任务没有调用-被调用的关系。然而,<a href="https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/7.TheConcurrencyAPI/item38.md">Item38</a>中也说说明了发送端是个<code>std::promise</code>,接收端是个<em>future</em>的通信信道不是只能用在调用-被调用场景。这样的通信信道可以用在任何你需要从程序一个地方传递信息到另一个地方的场景。这里,我们用来在检测任务和反应任务之间传递信息,传递的信息就是感兴趣的事件已经发生。</p>
<p>方案很简单。检测任务有一个<code>std::promise</code>对象(即通信信道的写入端),反应任务有对应的<em>future</em>。当检测任务看到事件已经发生,设置<code>std::promise</code>对象(即写入到通信信道)。同时,<code>wait</code>会阻塞住反应任务直到<code>std::promise</code>被设置。</p>
<p>现在,<code>std::promise</code><em>futures</em>(即<code>std::future</code><code>std::shared_future</code>)都是需要类型参数的模板。形参表明通过通信信道被传递的信息的类型。在这里,没有数据被传递,只需要让反应任务知道它的<em>future</em>已经被设置了。我们在<code>std::promise</code><em>future</em>模板中需要的东西是表明通信信道中没有数据被传递的一个类型。这个类型就是<code>void</code>。检测任务使用<code>std::promise&lt;void&gt;</code>,反应任务使用<code>std::future&lt;void&gt;</code>或者<code>std::shared_future&lt;void&gt;</code>。当感兴趣的事件发生时,检测任务设置<code>std::promise&lt;void&gt;</code>,反应任务在<em>future</em><code>wait</code>。尽管反应任务不从检测任务那里接收任何数据,通信信道也可以让反应任务知道,检测任务什么时候已经通过对<code>std::promise&lt;void&gt;</code>调用<code>set_value</code>“写入”了<code>void</code>数据。</p>
<p>所以,有</p>
<pre><code class="language-cpp">std::promise&lt;void&gt; p; //通信信道的promise
</code></pre>
<p>检测任务代码很简洁:</p>
<pre><code class="language-cpp">… //检测某个事件
p.set_value(); //通知反应任务
</code></pre>
<p>反应任务代码也同样简单:</p>
<pre><code class="language-cpp">… //准备作出反应
p.get_future().wait(); //等待对应于p的那个future
… //对事件作出反应
</code></pre>
<p>像使用flag的方法一样此设计不需要互斥锁无论在反应线程调用<code>wait</code>之前检测线程是否设置了<code>std::promise</code>都可以工作,并且不受虚假唤醒的影响(只有条件变量才容易受到此影响)。与基于条件变量的方法一样,反应任务在调用<code>wait</code>之后是真被阻塞住的,不会一直占用系统资源。是不是很完美?</p>
<p>当然不是,基于<em>future</em>的方法没有了上述问题,但是有其他新的问题。比如,<a href="https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/7.TheConcurrencyAPI/item38.md">Item38</a>中说明,<code>std::promise</code><em>future</em>之间有个共享状态,并且共享状态是动态分配的。因此你应该假定此设计会产生基于堆的分配和释放开销。</p>
<p>也许更重要的是,<code>std::promise</code>只能设置一次。<code>std::promise</code><em>future</em>之间的通信是<strong>一次性</strong>不能重复使用。这是与基于条件变量或者基于flag的设计的明显差异条件变量和flag都可以通信多次。条件变量可以被重复通知flag也可以重复清除和设置。</p>
<p>一次通信可能没有你想象中那么大的限制。假定你想创建一个挂起的系统线程。就是,你想避免多次线程创建的那种经常开销,以便想要使用这个线程执行程序时,避免潜在的线程创建工作。或者你想创建一个挂起的线程,以便在线程运行前对其进行设置这样的设置包括优先级或者核心亲和性(<em>core affinity</em>。C++并发API没有提供这种设置能力但是<code>std::thread</code>提供了<code>native_handle</code>成员函数它的结果就是提供给你对平台原始线程API的访问通常是POSIX或者Windows的线程。这些低层次的API使你可以对线程设置优先级和亲和性。</p>
<p>假设你仅仅想要对某线程挂起一次(在创建后,运行线程函数前),使用<code>void</code><em>future</em>就是一个可行方案。这是这个技术的关键点:</p>
<pre><code class="language-cpp">std::promise&lt;void&gt; p;
void react(); //反应任务的函数
void detect() //检测任务的函数
{
std::thread t([] //创建线程
{
p.get_future().wait(); //挂起t直到future被置位
react();
});
… //这里t在调用react前挂起
p.set_value(); //解除挂起t因此调用react
… //做其他工作
t.join(); //使t不可结合见条款37
}
</code></pre>
<p>因为所有离开<code>detect</code>的路径中<code>t</code>都要是不可结合的,所以使用类似于<a href="https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/7.TheConcurrencyAPI/item37.md">Item37</a><code>ThreadRAII</code>的RAII类很明智。代码如下</p>
<pre><code class="language-cpp">void detect()
{
ThreadRAII tr( //使用RAII对象
std::thread([]
{
p.get_future().wait();
react();
}),
ThreadRAII::DtorAction::join //有危险!(见下)
);
… //tr中的线程在这里被挂起
p.set_value(); //解除挂起tr中的线程
}
</code></pre>
<p>这样看起来安全多了。问题在于第一个“…”区域中(注释了“<code>tr</code>中的线程在这里被挂起”的那句),如果异常发生,<code>p</code>上的<code>set_value</code>永远不会调用,这意味着<em>lambda</em>中的<code>wait</code>永远不会返回。那意味着在<em>lambda</em>中运行的线程不会结束这是个问题因为RAII对象<code>tr</code>在析构函数中被设置为在(<code>tr</code>中创建的)那个线程上实行<code>join</code>。换句话说,如果在第一个“…”区域中发生了异常,函数挂起,因为<code>tr</code>的析构函数永远无法完成。</p>
<p>有很多方案解决这个问题,但是我把这个经验留给读者。(一个开始研究这个问题的好地方是我的博客<a href="http://scottmeyers.blogspot.com/"><em>The View From Aristeia</em></a>2013年12月24日的文章“<a href="http://scottmeyers.blogspot.com/2013/12/threadraii-thread-suspension-trouble.html">ThreadRAII + Thread Suspension = Trouble?</a>这里我只想展示如何扩展原始代码即不使用RAII类使其挂起然后取消挂起不仅一个反应任务而是多个任务。简单概括关键就是在<code>react</code>的代码中使用<code>std::shared_future</code>代替<code>std::future</code>。一旦你知道<code>std::future</code><code>share</code>成员函数将共享状态所有权转移到<code>share</code>产生的<code>std::shared_future</code>中,代码自然就写出来了。唯一需要注意的是,每个反应线程都需要自己的<code>std::shared_future</code>副本,该副本引用共享状态,因此通过<code>share</code>获得的<code>shared_future</code>要被在反应线程中运行的<em>lambda</em>按值捕获:</p>
<pre><code class="language-cpp">std::promise&lt;void&gt; p; //跟之前一样
void detect() //现在针对多个反映线程
{
auto sf = p.get_future().share(); //sf的类型是std::shared_future&lt;void&gt;
std::vector&lt;std::thread&gt; vt; //反应线程容器
for (int i = 0; i &lt; threadsToRun; ++i) {
vt.emplace_back([sf]{ sf.wait(); //在sf的局部副本上wait
react(); }); //emplace_back见条款42
}
… //如果这个“…”抛出异常detect挂起
p.set_value(); //所有线程解除挂起
for (auto&amp; t : vt) { //使所有线程不可结合;
t.join(); //“auto&amp;”见条款2
}
}
</code></pre>
<p>使用<em>future</em>的设计可以实现这个功能值得注意,这也是你应该考虑将其应用于一次通信的原因。</p>
<p><strong>请记住:</strong></p>
<ul>
<li>对于简单的事件通信,基于条件变量的设计需要一个多余的互斥锁,对检测和反应任务的相对进度有约束,并且需要反应任务来验证事件是否已发生。</li>
<li>基于flag的设计避免的上一条的问题但是是基于轮询而不是阻塞。</li>
<li>条件变量和flag可以组合使用但是产生的通信机制很不自然。</li>
<li>使用<code>std::promise</code><em>future</em>的方案避开了这些问题,但是这个方法使用了堆内存存储共享状态,同时有只能使用一次通信的限制。</li>
</ul>
</main>
<nav class="nav-wrapper" aria-label="Page navigation">
<!-- Mobile navigation buttons -->
<a rel="prev" href="../7.TheConcurrencyAPI/item38.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next" href="../7.TheConcurrencyAPI/item40.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
<div style="clear: both"></div>
</nav>
</div>
</div>
<nav class="nav-wide-wrapper" aria-label="Page navigation">
<a rel="prev" href="../7.TheConcurrencyAPI/item38.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next" href="../7.TheConcurrencyAPI/item40.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
</nav>
</div>
<script type="text/javascript">
window.playground_copyable = true;
</script>
<script src="../elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
<script src="../mark.min.js" type="text/javascript" charset="utf-8"></script>
<script src="../searcher.js" type="text/javascript" charset="utf-8"></script>
<script src="../clipboard.min.js" type="text/javascript" charset="utf-8"></script>
<script src="../highlight.js" type="text/javascript" charset="utf-8"></script>
<script src="../book.js" type="text/javascript" charset="utf-8"></script>
<!-- Custom JS scripts -->
</body>
</html>