第二章 執行緒管控
主要內容：
- 啟動執行緒，并通過幾種方式為新執行緒指定運行代碼
- 等待執行緒完成和分離執行緒并運行
- 唯一識別一個執行緒
2.1 執行緒的基本管控
? main函式其本聲就是一個執行緒，在其中又可以啟動別的執行緒和設定其對應的函式入口，
2.1.1 發起執行緒
? 不管執行緒要執行的任務是復雜還是簡單，其最終都要落實到標準庫
std::thread my_thread((background_task()));
下面我寫了一個驗證程式來驗證作者所說的這一種情況：
class background_task
{
public:
//函式轉化運算子，將類轉為函式物件
void operator()() const
{
cout<<"background_task's function convert"<<endl;
}
};
void func_inside_mythread()
{
cout<<"func_inside_mythread"<<endl;
}
//一個回傳background_task物件的函式
background_task do_something()
{
cout<<"do somthing inside background_task"<<endl;
return background_task();
}
//這里便是引發編譯器歧義的申明，這里既可以宣告為thread物件的創建也可以是一個引數為回傳background_task函式指標的函式
thread my_thread(background_task(*p)());
//如下便是對于上面t1的函式定義
thread my_thread(background_task(*p)())
{
(*p)();
cout<<"I am a function which get function pointer background_task"<<endl;
return thread(func_inside_mythread);
}
int main()
{
thread mt = my_thread(do_something);
mt.join();
return 0;
}
? 上面的t1就是引發編譯器歧義的地方，也就是作者所舉例說明的情況，下面來看一下執行結果:
? 可以發現編譯器把my_thread看作是了一個函式定義，但是實際上這里我傳入的引數是故意給了一個具名的回傳background_tast物件的p函式指標，實際上還可以這么寫：
int main()
{
//1
thread my_thread(background_task());
//2
background_task f;
thread my_thread(f);
return 0;
}
? main里的第一句，其實按照語法上來講，這里的backgroun_task類已經做過了函式型別轉化的操作了，在這里正常時可以解釋成我定義了一個thread執行緒物件，他接收可呼叫物件background_task函式，但是實際上通過vscode自帶的提示器，將滑鼠移動上去以后可以看見它仍然提示這是一個函式宣告：
? 那如何解決上述問題呢？其實就是書上說的C11以后引入了新式的統一初始化語法，也叫串列初始化，像下面這樣寫就不存在編譯器把這一行解釋成函式的情況了（或者還可以直接傳入lambda運算式做臨時函式變數也能解決問題）：
int main()
{
thread my_thread{background_task()};
my_thread.join();
return 0;
? 
? 接下來作者說到了執行緒的分離和匯合，這里要總結一個概念：如果什么都不設定，thread物件析構時將自動終止執行緒程式，如果分離，就算thread物件已經徹底析構了，執行緒程式還在自己繼續跑著，
? 這也接下來引發了第二個問題，即如果新執行緒的函式上持有指向主執行緒的變數或者資料的指標或參考時，但主執行緒運行退出后，新執行緒還沒結束時，這個時候再訪問那些指標的時候就是非法訪問了，書配套代碼如下：
#include <thread>
void do_something(int& i)
{
++i;
}
struct func
{
int& i;
func(int& i_):i(i_){}
void operator()()
{
//for(unsigned j=0;j<1000000;++j)
//這里為了復現非法訪問的情況改成了無限回圈
while(1)
{
do_something(i);
}
}
};
void oops()
{
int some_local_state=0;
func my_func(some_local_state);
std::thread my_thread(my_func);
my_thread.detach();
}
int main()
{
oops();
}
? 這里要引發的問題就在于，主執行緒detach以后結束了，自然區域變數得到釋放，但是新增的執行緒仍然還在跑著，因為傳的是參考型別，所以這個時候再去訪問就是非法訪問了，以下是我的運行結果，估計是Linux內部的什么機制，主執行緒一旦退出子執行緒隨即也退出的場景我沒有復現出來：
? 可以看見在gdb中切換到子行程以后輸入c命令讓程式自動運行，主執行緒775856先退出，隨后子行程立刻也跟著退出了，
? 解決上述問題的方法作者也給了出來，主要是兩點，一是讓執行緒函式完全自含（self-contained），另一種是使用thread的join函式，確保子行程在父行程之前退出，也就是匯合執行緒操作，如果想要更加精細化地控制執行緒等待，則要到后面講條件變數和future的時候繼續學習，一旦呼叫了join，則這個執行緒相關的任何存盤空間都將被立即洗掉，
2.1.3 在出現例外的情況下等待
? 接下來說到了在出現例外狀況下的join等待，主要的問題在于當新執行緒啟動以后，如果有例外拋出，但是這個時候join在例外的后面，這樣join就得不到執行了略過了，先來看一下代碼清單2.2中不用try-catch的情況：
#include <thread>
#include <iostream>
using namespace std;
void do_something(int& i)
{
++i;
}
struct func
{
int& i;
func(int& i_):i(i_){}
void operator()()
{
for(unsigned j=0;j<1000000;++j)
{
do_something(i);
}
}
};
void do_something_in_current_thread()
{
cout<<"do something error in current thread"<<endl;
}
void f()
{
int some_local_state=0;
func my_func(some_local_state);
std::thread t(my_func);
// try
// {
do_something_in_current_thread();
cout<< 3 / 0 <<endl;
//}
// catch(...)
// {
// t.join();
// throw;
// }
t.join();
}
int main()
{
f();
}
運行結果：通過gdb可以看到出現算術例外時，系統拋出了浮點運算錯誤，此時新執行緒2因為浮點錯誤直接終止了，但是此時主執行緒收到了子執行緒傳過來的SIGFPE信號，也終止了：
? 主執行緒隨后也收到了該信號終止：
? 下面展示成功捕捉到例外然后匯合的場景：
? 此處新執行緒在收到SIGFPE時，兩個執行緒同時終止，上述的使用try-catch捕獲例外的寫法其實稍顯冗余，更好的是使用標準RALL手法，如下面配套2.3代碼：
#include <thread>
#include <iostream>
using namespace std;
class thread_guard
{
std::thread& t;
public:
explicit thread_guard(std::thread& t_):
t(t_)
{}
~thread_guard()
{
if(t.joinable())
{
cout<<"Prepare to join"<<endl;
t.join();
}
}
//=delete不允許系統生成自己的默認拷貝和等號運算子多載
thread_guard(thread_guard const&)=delete;
thread_guard& operator=(thread_guard const&)=delete;
};
void do_something(int& i)
{
++i;
}
struct func
{
int& i;
func(int& i_):i(i_){}
void operator()()
{
for(unsigned j=0;j<1000000;++j)
{
do_something(i);
}
}
};
void do_something_in_current_thread()
{}
void f()
{
int some_local_state;
func my_func(some_local_state);
std::thread t(my_func);
thread_guard g(t);
do_something_in_current_thread();
}
int main()
{
f();
}
? 這里的要點是，利用析構的順序這個概念，thread_guard物件一定比thread物件t先析構，又用了RALL手法，所以一定可以匯合，不管后面出不出例外，以下是執行結果：
? 可以看出在執行緒2出現例外以后，主執行緒成功呼叫了join等待到了與2號執行緒匯合，
2.1.4 在后臺運行執行緒
? 這一節主要講了detach的用法以及一個模擬應用場景，提到了守護執行緒的概念：即和守護行程一樣，被分離出去的執行緒完全在后臺運行，其幾乎存在于整個應用程式生命周期內，配套代碼2.4給出了文字處理軟體編輯多檔案的多執行緒分離應用場景：
#include <thread>
#include <string>
void open_document_and_display_gui(std::string const& filename)
{}
bool done_editing()
{
return true;
}
enum command_type{
open_new_document
};
struct user_command
{
command_type type;
user_command():
type(open_new_document)
{}
};
user_command get_user_input()
{
return user_command();
}
std::string get_filename_from_user()
{
return "foo.doc";
}
void process_user_input(user_command const& cmd)
{}
void edit_document(std::string const& filename)
{
open_document_and_display_gui(filename);
//while(!done_editing())
for(int i = 0 ;i < 3 ;i++)
{
user_command cmd=get_user_input();
if(cmd.type==open_new_document)
{
std::string const new_name=get_filename_from_user();
std::thread t(edit_document,new_name);
t.detach();
}
else
{
process_user_input(cmd);
}
}
}
int main()
{
edit_document("bar.doc");
}
? 主要是模擬多執行緒處理程序，這里就跳過執行結果了，
2.2 向執行緒函式傳遞引數
? 首先總結一個概念：執行緒的內部是有存盤空間的，任何傳遞給執行緒的函式引數都會默認先被復制到該處，隨后新執行緒才能訪問他們，再然后這些副本被當做右值傳給執行緒上的可呼叫物件，
? 上述的概念引出了書中說的第一個錯誤，示例如下：
void f(int i,std::string const& s);
void oops(int some_param)
{
char buffer[1024]; // ?--- ①
sprintf(buffer, "%i",some_param);
std::thread t(f,3,buffer); // ?--- ②
t.detach();
}
? 這里的問題在于，因為thread的建構式需要原樣復制所提供的值，然后再轉換成可呼叫物件引數的預期型別，所以有可能oops在這個復制程序中先行崩潰或者退出，導致區域變數buffer被銷毀而引發未定義的行為，所以作者提出的解決辦法是先給他手工轉成string：
std::string(buffer)
? 然后再傳進去就行了，
? 另一個場景剛好相反，也就是我們期望引數型別是非const參考，而岸上上述的thread構造概念，整個物件卻被完全復制了一遍，這個是不合理的情況，編譯也過不了，這里作者沒給出示例代碼，我寫了一段驗證之：
#include <thread>
#include <iostream>
#include <condition_variable>
#include <queue>
#include <mutex>
#include <stdlib.h>
#include <string.h>
using namespace std;
struct widget_id
{
int id;
};
struct widget_data
{
};
void update_data_for_widget(widget_id w, widget_data & data)
{
}
void oops_again(widget_id w)
{
widget_data data;
//正確情況
//thread t(update_data_for_widget,w,ref(data));
//非正確，編譯錯誤
thread t(update_data_for_widget,w,data);
t.join();
}
int main()
{
oops_again(widget_id());
return 0;
}
? 編譯錯誤顯示如下：
? 這里的解決方案是利用標準的std::ref函式做一層包裝，把它強制轉成左值參考傳入，這里其實內部還有的講（即為什么ref之后就會忽略thread構造本身需要復制一遍的事實呢？這里其實是內部用forward實作了完美轉發），參考型別按照原先的型別傳遞到了執行緒的可呼叫物件引數串列中，
? bind函式和thread構造的引數傳遞機制其實很相似，下一部分作者提到了如何將一個類的非靜態成員函式最為thread的呼叫物件的，其原理譯者在下方1號注釋中做了說明，
2.3 移交執行緒歸屬權
? 如果thread物件正在管理一個執行緒，就不能簡單地向他賦新值，否則新執行緒會因此被遺棄，這一節主要講的是移動語意和執行緒歸屬權相互移交的程序，代碼清單2-5展示了從函式內部回傳thread物件，清單2-6和之前的2-3很相似，只不過在建構式用了移動語意直接去構造要接管的thread物件，以及本來要引入C17的joining_thread類，這里就不做展示和演示了，
? 清單2.7展示了執行緒管控自動化切分的簡單實作，用vector管理了一堆執行緒：
#include <vector>
#include <thread>
#include <algorithm>
#include <functional>
void do_work(unsigned id)
{}
void f()
{
std::vector<std::thread> threads;
for(unsigned i=0;i<20;++i)
{
threads.push_back(std::thread(do_work,i));
}
std::for_each(threads.begin(),threads.end(),
std::mem_fn(&std::thread::join));
}
int main()
{
f();
}
? 這里使用了標準的mem_fn，回傳一個指向其引數函式的函式指標用于foreach遍歷，
2.4 在運行時選擇執行緒數量
? 這章簡單實作了一個并行版本的accumulate，無特別說明，看懂代碼和說明即可，
2.5 識別執行緒
? 主要介紹了執行緒id，如何獲取它（呼叫thread.get_id）,獲取當前執行緒的方法（this_thread）以及標準庫對其實作了全面的比較運算子支持，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/541989.html
標籤：其他
上一篇：陣列
下一篇：Python之字典添加元素