第二章 線程管控

来源:https://www.cnblogs.com/Janos/archive/2023/01/14/17052312.html
-Advertisement-
Play Games

第二章 線程管控 主要內容： 啟動線程，並通過幾種方式為新線程指定運行代碼 等待線程完成和分離線程並運行 唯一識別一個線程 2.1 線程的基本管控 ​ main函數其本聲就是一個線程，在其中又可以啟動別的線程和設置其對應的函數入口。 2.1.1 發起線程 ​ 不管線程要執行的任務是複雜還是簡單，其最 ...


第二章 線程管控

主要內容：

  • 啟動線程，並通過幾種方式為新線程指定運行代碼
  • 等待線程完成和分離線程並運行
  • 唯一識別一個線程

2.1 線程的基本管控

​ main函數其本聲就是一個線程，在其中又可以啟動別的線程和設置其對應的函數入口。

2.1.1 發起線程

​ 不管線程要執行的任務是複雜還是簡單，其最終都要落實到標準庫的std::thread對象的創建，書中這一章作者提到了所謂的“C++最麻煩的解釋”：將函數對象傳遞給std::thread對象時，傳入的是臨時對象，而不是具名對象時，編譯器會將其解釋為函數聲明而不是定義對象，這一塊書中其實沒有給出具體的代碼示例，只是給出瞭如下的一個聲明：

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）以及標準庫對其實現了全面的比較運算符支持。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 大牛架構師珍藏的10條編程原則
    程式員擁有一個較好的編程原則能使他的編程能力有大幅的提升，可以使其開發出維護性高、缺陷更少的代碼。以下內容梳理自StactOverflow的一個問題：編程時你最先考慮的準則是什麼？ ...
  • 基於狀態機的按鍵消抖模塊
    本次案例是按著小梅哥的思路來寫的，部分截圖和文字來自其教學視頻。 1、狀態機的設定 2、模塊代碼 `timescale 1ns / 1ps //////////////////////////////////////////////////////////////////////////////// ...
  • 通過Google Cloud Storage(GCS)管理Terraform的狀態State
    管理Terraform狀態文件的最佳方式是通過雲端的統一的存儲，如谷歌雲就用GCS。 首先要創建一個Bucket： $ gsutil mb -p pkslow -l us-west1 -b on gs://pkslow-terraform Creating gs://pkslow-terraform ...
  • java中的基本類型
    引入我們前面使用過了輸出語句System.out.println();知道了它能夠輸出( )里的東西但是它到底能夠輸出一些什麼東西呢，或者直奔主題它能夠輸出什麼類型呢可以嘗試一下，如果我們輸入的直接是abcd，那麼顯然不行，它已經在報紅了，編譯器根本不認識它，表示錯誤你不能這樣子寫再嘗試一下，我們之 ...
  • day01-Spring基本介紹
    Spring基本介紹 1.官方資料和下載 1.1Spring5下載 直接訪問 https://repo.spring.io/ui/native/release/org/springframework/spring/，選擇相應版本即可 進入官網 https://spring.io/ 進入Spring5 ...
  • PHP實現動態修改.env文件配置（適用於任何框架）
    /** * @function 動態的設置env文件中某項配置值 * @param $env_path string env文件路徑 * @param $key string 配置項 * @param $val string|int 配置值 * @return bool 返回是否成功修改 * @ot ...
  • StringBuffer類
    StringBuffer類 一、 結構剖析 Java.lang.StringBuffer 代表可變的字元序列，可以對字元串內容進行增刪。 很多方法與String相同，但StringBuffer是可變長度的。 StringBuffer是一個容器。 String VS StringBuffer Stri ...
  • Python之字典添加元素
    本文使用代碼 book_dict = {"price": 500, "bookName": "Python設計", "weight": "250g"} 第一種方式：使用[] book_dict["owner"] = "tyson" 說明：中括弧指定key，賦值一個value，key不存在，則是添加元 ...
一周排行
    -Advertisement-
    Play Games
  • C#自增運算符詳解：++i與i++的區別及應用場景
    概述：在C#中，++i和i++都是自增運算符，其中++i先增加值再返回，而i++先返回值再增加。應用場景根據需求選擇，首碼適合先增後用，尾碼適合先用後增。詳細示例提供清晰的代碼演示這兩者的操作時機和實際應用。 在C#中，++i 和 i++ 都是自增運算符，但它們在操作上有細微的差異，主要體現在操作的 ...
  • Taurus.MVC 性能壓力測試（ap 壓測 和 linux 下wrk 壓測）：.NET 版本
    上次發佈了：Taurus.MVC 性能壓力測試（ap 壓測 和 linux 下wrk 壓測）：.NET Core 版本，今天計劃準備壓測一下 .NET 版本，來測試並記錄一下 Taurus.MVC 框架在 .NET 版本的性能，以便後續持續優化改進。 為了方便對比，本文章的電腦環境和測試思路，儘量和... ...
  • 一文讀懂.NET WebAPI中FromRoute、FromQuery、FromBody的關鍵角色與用法
    .NET WebAPI作為一種構建RESTful服務的強大工具，為開發者提供了便捷的方式來定義、處理HTTP請求並返迴響應。在設計API介面時，正確地接收和解析客戶端發送的數據至關重要。.NET WebAPI提供了一系列特性，如[FromRoute]、[FromQuery]和[FromBody]，用 ...
  • WPF/C#實現圖像濾鏡優化方案：打造炫目視覺體驗！
    原因：我之所以想做這個項目，是因為在之前查找關於C#/WPF相關資料時，我發現講解圖像濾鏡的資源非常稀缺。此外，我註意到許多現有的開源庫主要基於CPU進行圖像渲染。這種方式在處理大量圖像時，會導致CPU的渲染負擔過重。因此，我將在下文中介紹如何通過GPU渲染來有效實現圖像的各種濾鏡效果。 生成的效果 ...
  • Bogus 實戰：使用 Bogus 和 EFCore 生成模擬數據和種子數據【完整教程】
    引言 上一章我們介紹了在xUnit單元測試中用xUnit.DependencyInject來使用依賴註入，上一章我們的Sample.Repository倉儲層有一個批量註入的介面沒有做單元測試，今天用這個示例來演示一下如何用Bogus創建模擬數據 ，和 EFCore 的種子數據生成 Bogus 的優 ...
  • WPF隨筆收錄-實時繪製心率曲線
    一、前言 在自己的項目中，涉及到實時心率曲線的繪製，項目上的曲線繪製，一般很難找到能直接用的第三方庫，而且有些還是定製化的功能，所以還是自己繪製比較方便。很多人一聽到自己畫就害怕，感覺很難，今天就分享一個完整的實時心率數據繪製心率曲線圖的例子；之前的博客也分享給DrawingVisual繪製曲線的方 ...
  • wpf程式修改啟動入口註意事項
    如果你在自定義的 Main 方法中直接使用 App 類並啟動應用程式，但發現 App.xaml 中定義的資源沒有被正確載入，那麼問題可能在於如何正確配置 App.xaml 與你的 App 類的交互。 確保 App.xaml 文件中的 x:Class 屬性正確指向你的 App 類。這樣，當你創建 Ap ...
  • 記一次 .NET某爐膛鍋爐檢測系統 崩潰分析
    一：背景 1. 講故事 上個月有個朋友在微信上找到我，說他們的軟體在客戶那邊隔幾天就要崩潰一次，一直都沒有找到原因，讓我幫忙看下怎麼回事，確實工控類的軟體環境複雜難搞，朋友手上有一個崩潰的dump，剛好丟給我來分析一下。 二：WinDbg分析 1. 程式為什麼會崩潰 windbg 有一個厲害之處在於 ...
  • 一個.NET內置依賴註入的小型強化版
    前言 .NET生態中有許多依賴註入容器。在大多數情況下，微軟提供的內置容器在易用性和性能方面都非常優秀。外加ASP.NET Core預設使用內置容器，使用很方便。 但是筆者在使用中一直有一個頭疼的問題：服務工廠無法提供請求的服務類型相關的信息。這在一般情況下並沒有影響，但是內置容器支持註冊開放泛型服 ...
  • WPF隨筆收錄-DataGrid固定右側列
    一、前言 在項目開發過程中，DataGrid是經常使用到的一個數據展示控制項，而通常表格的最後一列是作為操作列存在，比如會有編輯、刪除等功能按鈕。但WPF的原始DataGrid中，預設只支持固定左側列，這跟大家習慣性操作列放最後不符，今天就來介紹一種簡單的方式實現固定右側列。（這裡的實現方式參考的大佬 ...
所有分類