協(xié)程

協(xié)程，即協(xié)作式程序，其思想是，一系列互相依賴的協(xié)程間依次使用CPU，每次只有一個(gè)協(xié)程工作，而其他協(xié)程處于休眠狀態(tài)。協(xié)程可以在運(yùn)行期間的某個(gè)點(diǎn)上暫停執(zhí)行，并在恢復(fù)運(yùn)行時(shí)從暫停的點(diǎn)上繼續(xù)執(zhí)行。 協(xié)程已經(jīng)被證明是一種非常有用的程序組件，不僅被python、lua、ruby等腳本語言廣泛采用，而且被新一代面向多核的編程語言如golang rust-lang等采用作為并發(fā)的基本單位。 協(xié)程可以被認(rèn)為是一種用戶空間線程，與傳統(tǒng)的線程相比，有2個(gè)主要的優(yōu)點(diǎn)：

• 與線程不同，協(xié)程是自己主動(dòng)讓出CPU，并交付他期望的下一個(gè)協(xié)程運(yùn)行，而不是在任何時(shí)候都有可能被系統(tǒng)調(diào)度打斷。因此協(xié)程的使用更加清晰易懂，并且多數(shù)情況下不需要鎖機(jī)制。
• 與線程相比，協(xié)程的切換由程序控制，發(fā)生在用戶空間而非內(nèi)核空間，因此切換的代價(jià)非常小。

網(wǎng)絡(luò)編程模型

首先來簡(jiǎn)單回顧一下一些常用的網(wǎng)絡(luò)編程模型。網(wǎng)絡(luò)編程模型可以大體的分為同步模型和異步模型兩類。

• 同步模型：

同步模型使用阻塞IO模式,在阻塞IO模式下調(diào)用read等IO函數(shù)時(shí)會(huì)阻塞線程直到IO完成或失敗。

同步模型的典型代表是thread per connection模型，每當(dāng)阻塞在主線程上的accept調(diào)用返回時(shí)則創(chuàng)建一個(gè)新的線程去服務(wù)于新的socket的讀/寫。這種模型的優(yōu)點(diǎn)是程序簡(jiǎn)潔，編寫簡(jiǎn)單；缺點(diǎn)是可伸縮性收到線程數(shù)的限制，當(dāng)連接越來越多時(shí)，線程也越來越多，頻繁的線程切換會(huì)嚴(yán)重拖累性能。

• 異步模型：

異步模型一般使用非阻塞IO模式，并配合epoll/select/poll等多路復(fù)用機(jī)制。在非阻塞模式下調(diào)用read，如果沒有數(shù)據(jù)可讀則立即返回并通知用戶沒有可讀（EAGAIN/EWOULDBLOCK），而非阻塞當(dāng)前線程。異步模型可以使一個(gè)線程同時(shí)服務(wù)于多個(gè)IO對(duì)象。

異步模型的典型代表是reactor模型。在reactor模型中，我們將所有要處理的IO事件注冊(cè)到一個(gè)中心的IO多路復(fù)用器中（一般為epoll/select/poll），同時(shí)主線程阻塞在多路復(fù)用器上。一旦有IO事件到來或者就緒，多路復(fù)用器返回并將對(duì)應(yīng)的IO事件分發(fā)到對(duì)應(yīng)的處理器（即回調(diào)函數(shù)）中，最后處理器調(diào)用read/write函數(shù)來進(jìn)行IO操作。

異步模型的特點(diǎn)是性能和可伸縮性比同步模型要好很多，但是其結(jié)構(gòu)復(fù)雜，不易于編寫和維護(hù)。在異步模型中，IO之前的代碼（IO任務(wù)的提交者）和IO之后的處理代碼（回調(diào)函數(shù)）是割裂開來的。

協(xié)程與網(wǎng)絡(luò)編程

協(xié)程為克服同步模型和異步模型的缺點(diǎn)，并結(jié)合他們的優(yōu)點(diǎn)提供了可能： 現(xiàn)在假設(shè)我們有3個(gè)協(xié)程A,B,C分別要進(jìn)行數(shù)次IO操作。這3個(gè)協(xié)程運(yùn)行在同一個(gè)調(diào)度器或者說線程的上下文中，并依次使用CPU。調(diào)度器在其內(nèi)部維護(hù)了一個(gè)多路復(fù)用器（epoll/select/poll）。

協(xié)程A首先運(yùn)行，當(dāng)它執(zhí)行到一個(gè)IO操作，但該IO操作并沒有立即就緒時(shí)，A將該IO事件注冊(cè)到調(diào)度器中，并主動(dòng)放棄CPU。這時(shí)調(diào)度器將B切換到CPU上開始執(zhí)行，同樣，當(dāng)它碰到一個(gè)IO操作的時(shí)候?qū)O事件注冊(cè)到調(diào)度器中，并主動(dòng)放棄CPU。調(diào)度器將C切換到cpu上開始執(zhí)行。當(dāng)所有協(xié)程都被“阻塞”后，調(diào)度器檢查注冊(cè)的IO事件是否發(fā)生或就緒。假設(shè)此時(shí)協(xié)程B注冊(cè)的IO時(shí)間已經(jīng)就緒，調(diào)度器將恢復(fù)B的執(zhí)行，B將從上次放棄CPU的地方接著向下運(yùn)行。A和C同理。

這樣，對(duì)于每一個(gè)協(xié)程來說，是同步的模型；但是對(duì)于整個(gè)應(yīng)用程序來說，卻是異步的模型。

好了，原理說完了，我們來看一個(gè)實(shí)際的例子，echo server。

echo server

在這個(gè)例子中，我們將使用orchid庫來編寫一個(gè)echo server。orchid庫是一個(gè)構(gòu)建于boost基礎(chǔ)上的 協(xié)程/網(wǎng)絡(luò)IO 庫。

echo server首先必須要處理連接事件，我們創(chuàng)建一個(gè)協(xié)程來專門處理連接事件：

typedef boost::shared_ptr<orchid::socket> socket_ptr; 
//處理ACCEPT事件的協(xié)程 
void handle_accept(orchid::coroutine_handle co) {
     try {         
         orchid::acceptor acceptor(co -> get_scheduler().get_io_service());//構(gòu)建一個(gè)acceptor
         acceptor.bind_and_listen("5678",true);         
         for(;;) {             
            socket_ptr sock(new orchid::socket(co -> get_scheduler().get_io_service()));
            acceptor.accept(*sock,co);             
            //在調(diào)度器上創(chuàng)建一個(gè)協(xié)程來服務(wù)新的socket。第一個(gè)參數(shù)是要?jiǎng)?chuàng)建的協(xié)程的main函數(shù)，第二個(gè)參數(shù)是要?jiǎng)?chuàng)建的協(xié)程的棧的大小。
            co -> get_scheduler().spawn(boost::bind(handle_io,_1,sock),orchid::minimum_stack_size());
         }
     } catch(boost::system::system_error& e) {
            cerr<<e.code()<<" "<<e.what()<<endl;
     } 
} 

在orchid中，協(xié)程的main函數(shù)必須滿足函數(shù)簽名void(orchid::coroutine_handle)，如handle_accept所示，其中參數(shù)co是協(xié)程句柄，代表了當(dāng)前函數(shù)所位于的協(xié)程。

在上面的代碼中，我們創(chuàng)建了一個(gè)acceptor，并讓它監(jiān)聽5678端口，然后在"阻塞"等待連接到來，當(dāng)連接事件到來時(shí)，創(chuàng)建一個(gè)新的協(xié)程來服務(wù)新的socket。處理套接字IO的協(xié)程如下：

//處理SOCKET IO事件的協(xié)程 
void handle_io(orchid::coroutine_handle co,socket_ptr sock) {     
   orchid::tcp_ostream out(*sock,co);     
   orchid::tcp_istream in(*sock,co);     
   for(std::string str;std::getline(in, str) && out;) {
      out<<str<<endl;     
   }  
} 

IO處理協(xié)程首先在傳入的套接字上創(chuàng)建了一個(gè)輸入流和一個(gè)輸出流，分別代表了TCP的輸入和輸出。然后不斷地從輸入流中讀取一行，并輸出到輸出流當(dāng)中。當(dāng)socket上的TCP連接斷開時(shí)，輸入流和輸出流的eof標(biāo)志為會(huì)被置位，因此循環(huán)結(jié)束，協(xié)程退出。

orchid可以使用戶以流的形式來操作套接字。輸入流和輸出流分別提供了std::istream和std::ostream的接口；輸入流和輸出流是帶緩沖的，如果用戶需要無緩沖的讀寫socket或者自建緩沖，可以直接調(diào)用orchid::socket的read和write函數(shù)。但是需要注意這兩個(gè)函數(shù)會(huì)拋出boost::system_error異常來表示錯(cuò)誤。

細(xì)心的讀者可能已經(jīng)發(fā)現(xiàn)，handle_io的函數(shù)簽名并不滿足void(orchid::coroutine_handle)，回到handle_accept中，可以發(fā)現(xiàn)，實(shí)際上我們使用了boost.bind對(duì)handle _ io函數(shù)進(jìn)行了適配，使之符合函數(shù)簽名的要求。

最后是main函數(shù)：

int main() {     
   orchid::scheduler sche;     
   sche.spawn(handle_accept,orchid::coroutine::minimum_stack_size());//創(chuàng)建協(xié)程     
   sche.run(); 
} 

在上面這個(gè)echo server的例子中，我們采用了一種 coroutine per connection 的編程模型，與傳統(tǒng)的 thread per connection 模型一樣的簡(jiǎn)潔清晰，但是整個(gè)程序?qū)嶋H上運(yùn)行在同一線程當(dāng)中。

由于協(xié)程的切換開銷遠(yuǎn)遠(yuǎn)小于線程，因此我們可以輕易的同時(shí)啟動(dòng)上千協(xié)程來同時(shí)服務(wù)上千連接，這是 thread per connection的模型很難做到的；在性能方面，整個(gè)底層的IO系統(tǒng)實(shí)際上是使用boost.asio這種高性能的異步io庫實(shí)現(xiàn)的。而且與IO所費(fèi)的時(shí)間相比，協(xié)程切換的開銷基本可以忽略。

因此通過協(xié)程，我們可以在保持同步IO模型簡(jiǎn)潔性的同時(shí)，獲得近似于異步IO模型的高性能。

協(xié)程

協(xié)程，即協(xié)作式程序，其思想是，一系列互相依賴的協(xié)程間依次使用CPU，每次只有一個(gè)協(xié)程工作，而其他協(xié)程處于休眠狀態(tài)。協(xié)程可以在運(yùn)行期間的某個(gè)點(diǎn)上暫停執(zhí)行，并在恢復(fù)運(yùn)行時(shí)從暫停的點(diǎn)上繼續(xù)執(zhí)行。 協(xié)程已經(jīng)被證明是一種非常有用的程序組件，不僅被python、lua、ruby等腳本語言廣泛采用，而且被新一代面向多核的編程語言如golang rust-lang等采用作為并發(fā)的基本單位。 協(xié)程可以被認(rèn)為是一種用戶空間線程，與傳統(tǒng)的線程相比，有2個(gè)主要的優(yōu)點(diǎn)：

• 與線程不同，協(xié)程是自己主動(dòng)讓出CPU，并交付他期望的下一個(gè)協(xié)程運(yùn)行，而不是在任何時(shí)候都有可能被系統(tǒng)調(diào)度打斷。因此協(xié)程的使用更加清晰易懂，并且多數(shù)情況下不需要鎖機(jī)制。
• 與線程相比，協(xié)程的切換由程序控制，發(fā)生在用戶空間而非內(nèi)核空間，因此切換的代價(jià)非常小。

網(wǎng)絡(luò)編程模型

首先來簡(jiǎn)單回顧一下一些常用的網(wǎng)絡(luò)編程模型。網(wǎng)絡(luò)編程模型可以大體的分為同步模型和異步模型兩類。

• 同步模型：

同步模型使用阻塞IO模式,在阻塞IO模式下調(diào)用read等IO函數(shù)時(shí)會(huì)阻塞線程直到IO完成或失敗。

同步模型的典型代表是thread per connection模型，每當(dāng)阻塞在主線程上的accept調(diào)用返回時(shí)則創(chuàng)建一個(gè)新的線程去服務(wù)于新的socket的讀/寫。這種模型的優(yōu)點(diǎn)是程序簡(jiǎn)潔，編寫簡(jiǎn)單；缺點(diǎn)是可伸縮性收到線程數(shù)的限制，當(dāng)連接越來越多時(shí)，線程也越來越多，頻繁的線程切換會(huì)嚴(yán)重拖累性能。

• 異步模型：

異步模型一般使用非阻塞IO模式，并配合epoll/select/poll等多路復(fù)用機(jī)制。在非阻塞模式下調(diào)用read，如果沒有數(shù)據(jù)可讀則立即返回并通知用戶沒有可讀（EAGAIN/EWOULDBLOCK），而非阻塞當(dāng)前線程。異步模型可以使一個(gè)線程同時(shí)服務(wù)于多個(gè)IO對(duì)象。

異步模型的典型代表是reactor模型。在reactor模型中，我們將所有要處理的IO事件注冊(cè)到一個(gè)中心的IO多路復(fù)用器中（一般為epoll/select/poll），同時(shí)主線程阻塞在多路復(fù)用器上。一旦有IO事件到來或者就緒，多路復(fù)用器返回并將對(duì)應(yīng)的IO事件分發(fā)到對(duì)應(yīng)的處理器（即回調(diào)函數(shù)）中，最后處理器調(diào)用read/write函數(shù)來進(jìn)行IO操作。

異步模型的特點(diǎn)是性能和可伸縮性比同步模型要好很多，但是其結(jié)構(gòu)復(fù)雜，不易于編寫和維護(hù)。在異步模型中，IO之前的代碼（IO任務(wù)的提交者）和IO之后的處理代碼（回調(diào)函數(shù)）是割裂開來的。

協(xié)程與網(wǎng)絡(luò)編程

協(xié)程為克服同步模型和異步模型的缺點(diǎn)，并結(jié)合他們的優(yōu)點(diǎn)提供了可能： 現(xiàn)在假設(shè)我們有3個(gè)協(xié)程A,B,C分別要進(jìn)行數(shù)次IO操作。這3個(gè)協(xié)程運(yùn)行在同一個(gè)調(diào)度器或者說線程的上下文中，并依次使用CPU。調(diào)度器在其內(nèi)部維護(hù)了一個(gè)多路復(fù)用器（epoll/select/poll）。

協(xié)程A首先運(yùn)行，當(dāng)它執(zhí)行到一個(gè)IO操作，但該IO操作并沒有立即就緒時(shí)，A將該IO事件注冊(cè)到調(diào)度器中，并主動(dòng)放棄CPU。這時(shí)調(diào)度器將B切換到CPU上開始執(zhí)行，同樣，當(dāng)它碰到一個(gè)IO操作的時(shí)候?qū)O事件注冊(cè)到調(diào)度器中，并主動(dòng)放棄CPU。調(diào)度器將C切換到cpu上開始執(zhí)行。當(dāng)所有協(xié)程都被“阻塞”后，調(diào)度器檢查注冊(cè)的IO事件是否發(fā)生或就緒。假設(shè)此時(shí)協(xié)程B注冊(cè)的IO時(shí)間已經(jīng)就緒，調(diào)度器將恢復(fù)B的執(zhí)行，B將從上次放棄CPU的地方接著向下運(yùn)行。A和C同理。

這樣，對(duì)于每一個(gè)協(xié)程來說，是同步的模型；但是對(duì)于整個(gè)應(yīng)用程序來說，卻是異步的模型。

好了，原理說完了，我們來看一個(gè)實(shí)際的例子，echo server。

echo server

在這個(gè)例子中，我們將使用orchid庫來編寫一個(gè)echo server。orchid庫是一個(gè)構(gòu)建于boost基礎(chǔ)上的 協(xié)程/網(wǎng)絡(luò)IO 庫。

echo server首先必須要處理連接事件，我們創(chuàng)建一個(gè)協(xié)程來專門處理連接事件：

typedef boost::shared_ptr<orchid::socket> socket_ptr; 
//處理ACCEPT事件的協(xié)程 
void handle_accept(orchid::coroutine_handle co) {
     try {         
         orchid::acceptor acceptor(co -> get_scheduler().get_io_service());//構(gòu)建一個(gè)acceptor
         acceptor.bind_and_listen("5678",true);         
         for(;;) {             
            socket_ptr sock(new orchid::socket(co -> get_scheduler().get_io_service()));
            acceptor.accept(*sock,co);             
            //在調(diào)度器上創(chuàng)建一個(gè)協(xié)程來服務(wù)新的socket。第一個(gè)參數(shù)是要?jiǎng)?chuàng)建的協(xié)程的main函數(shù)，第二個(gè)參數(shù)是要?jiǎng)?chuàng)建的協(xié)程的棧的大小。
            co -> get_scheduler().spawn(boost::bind(handle_io,_1,sock),orchid::minimum_stack_size());
         }
     } catch(boost::system::system_error& e) {
            cerr<<e.code()<<" "<<e.what()<<endl;
     } 
} 

在orchid中，協(xié)程的main函數(shù)必須滿足函數(shù)簽名void(orchid::coroutine_handle)，如handle_accept所示，其中參數(shù)co是協(xié)程句柄，代表了當(dāng)前函數(shù)所位于的協(xié)程。

在上面的代碼中，我們創(chuàng)建了一個(gè)acceptor，并讓它監(jiān)聽5678端口，然后在"阻塞"等待連接到來，當(dāng)連接事件到來時(shí)，創(chuàng)建一個(gè)新的協(xié)程來服務(wù)新的socket。處理套接字IO的協(xié)程如下：

//處理SOCKET IO事件的協(xié)程 
void handle_io(orchid::coroutine_handle co,socket_ptr sock) {     
   orchid::tcp_ostream out(*sock,co);     
   orchid::tcp_istream in(*sock,co);     
   for(std::string str;std::getline(in, str) && out;) {
      out<<str<<endl;     
   }  
} 

IO處理協(xié)程首先在傳入的套接字上創(chuàng)建了一個(gè)輸入流和一個(gè)輸出流，分別代表了TCP的輸入和輸出。然后不斷地從輸入流中讀取一行，并輸出到輸出流當(dāng)中。當(dāng)socket上的TCP連接斷開時(shí)，輸入流和輸出流的eof標(biāo)志為會(huì)被置位，因此循環(huán)結(jié)束，協(xié)程退出。

orchid可以使用戶以流的形式來操作套接字。輸入流和輸出流分別提供了std::istream和std::ostream的接口；輸入流和輸出流是帶緩沖的，如果用戶需要無緩沖的讀寫socket或者自建緩沖，可以直接調(diào)用orchid::socket的read和write函數(shù)。但是需要注意這兩個(gè)函數(shù)會(huì)拋出boost::system_error異常來表示錯(cuò)誤。

細(xì)心的讀者可能已經(jīng)發(fā)現(xiàn)，handle_io的函數(shù)簽名并不滿足void(orchid::coroutine_handle)，回到handle_accept中，可以發(fā)現(xiàn)，實(shí)際上我們使用了boost.bind對(duì)handle _ io函數(shù)進(jìn)行了適配，使之符合函數(shù)簽名的要求。

最后是main函數(shù)：

int main() {     
   orchid::scheduler sche;     
   sche.spawn(handle_accept,orchid::coroutine::minimum_stack_size());//創(chuàng)建協(xié)程     
   sche.run(); 
} 

在上面這個(gè)echo server的例子中，我們采用了一種 coroutine per connection 的編程模型，與傳統(tǒng)的 thread per connection 模型一樣的簡(jiǎn)潔清晰，但是整個(gè)程序?qū)嶋H上運(yùn)行在同一線程當(dāng)中。

由于協(xié)程的切換開銷遠(yuǎn)遠(yuǎn)小于線程，因此我們可以輕易的同時(shí)啟動(dòng)上千協(xié)程來同時(shí)服務(wù)上千連接，這是 thread per connection的模型很難做到的；在性能方面，整個(gè)底層的IO系統(tǒng)實(shí)際上是使用boost.asio這種高性能的異步io庫實(shí)現(xiàn)的。而且與IO所費(fèi)的時(shí)間相比，協(xié)程切換的開銷基本可以忽略。

因此通過協(xié)程，我們可以在保持同步IO模型簡(jiǎn)潔性的同時(shí)，獲得近似于異步IO模型的高性能。

C++11中有很多激動(dòng)人心的特性,但是相應(yīng)的使得C++更加復(fù)雜。。。
新標(biāo)準(zhǔn)還修改了原有標(biāo)準(zhǔn)庫，并增加了很多內(nèi)容。

在學(xué)習(xí)新標(biāo)準(zhǔn)的過程中動(dòng)手寫了個(gè) 為std::tuple增加格式化/序列化能力的一小段代碼

#define DECLARE_TUPLE_SERIALIZATION_FUNCTION(FUNC_NAME,BEG,SEP,END)     \
namespace sjdfsjfyttsaihfah6755jsdf554433356sdf{                        \
template <typename Tuple,std::size_t N>                                 \
struct tuple_printer                                                    \
{                                                                       \
    static void print(std::ostream& os,const Tuple& t)                  \
    {                                                                   \
        os<<std::get<std::tuple_size<Tuple>::value - N >(t)<<SEP;       \
        tuple_printer<Tuple,N-1>::print(os,t);                          \
    }                                                                   \
};                                                                      \
                                                                        \
template <typename Tuple>                                               \
struct tuple_printer<Tuple,1>                                           \
{                                                                       \
    static void print(std::ostream& os,const Tuple& t)                  \
    {                                                                   \
        os<<std::get<std::tuple_size<Tuple>::value-1>(t);               \
    }                                                                   \
};                                                                      \
}                                                                       \
template <typename Tuple>                                               \
void FUNC_NAME(std::ostream& os,const Tuple& t)                         \
{                                                                       \
    os<<BEG;                                                            \
    sjdfsjfyttsaihfah6755jsdf554433356sdf::tuple_printer<Tuple,std::tuple_size<Tuple>::value>::print(os,t);    \
    os<<END;                                                            \
}                                                                       

實(shí)現(xiàn)成宏是為了使用起來更方便，可以隨意指定 函數(shù)名 前綴 分隔符 和 后綴。
使用方法如下：

DECLARE_TUPLE_SERIALIZATION_FUNCTION(serialize_tuple,"<"," , ",">")

int main()
{
    int i=10;
    auto a = std::make_tuple(3,"lala",i,'c');
    serialize_tuple(std::cout,a); 
}

輸出為：
<3 , "lala" , 10 , c>

測(cè)試環(huán)境為GCC 4.5，注意編譯時(shí)候請(qǐng)打開C++0X支持。

題目二：
   題目我做了下改變，使用了上篇文章中提到的那個(gè)類X，代碼如下：

 1 class X
 2 {
 3 public:
 4     X(){cout<<"default construct"<<endl;}
 5     X(int a):i(a){ cout<<"construct "<<i<<endl;}
 6     ~X(){ cout<<"desconstruct "<<i<<endl;}
 7     X(const X& x):i(x.i)
 8     {
 9         cout<<"copy construct "<<i<<endl;
10     }
11     X& operator++()
12     {
13         cout<<"operator ++(pre) "<<i<<endl;
14         ++i;
15         return *this;
16     }
17     const X operator++(int)
18     {
19         cout<<"operator ++(post) "<<i<<endl;
20         X x(*this);
21         ++i;
22         return x;
23     }
24     X& operator=(int m)
25     {
26         cout<<"operator =(int)"<<endl;
27         i = m;
28         return *this;
29     }
30     X& operator=(const X& x)
31     {
32         cout<<"operator =(X)"<<endl;
33         i=x.i;
34         return *this;
35     }
36     /////////////////////////
37     friend ostream& operator<<(ostream& os,const X& x)
38     {
39         os<<x.i;
40         return os;
41     }
42     friend X operator+(const X& a,const X& b)
43     {
44         cout<<"operator +"<<endl;
45         return X(a.i+b.i);
46     }
47     //////////////////////////
48 public:
49     int i;
50 };

請(qǐng)問以下代碼的輸出是什么？


我們來看一下使用GCC4.5（默認(rèn)編譯選項(xiàng)）以及MSVC9.0(BOTH DEBUG AND RELEASE)編譯后的實(shí)際運(yùn)行結(jié)果：
今年要開始找工作了，本著積累經(jīng)驗(yàn)的目的，跑去做了下MTK的筆試題，筆試的內(nèi)容主要是C＋＋。
因?yàn)殚_發(fā)中一直使用C＋＋，而且對(duì)C＋＋里的高級(jí)特性：面向?qū)ο?，模板等都比較熟悉，還沒事喜歡研究下STL，BOOST，所以對(duì)自己的C＋＋水平比較自信，因此事先也沒做任何準(zhǔn)備，就直接去筆試了。本來筆試完了后覺得題目蠻簡(jiǎn)單的，但是本著認(rèn)真學(xué)習(xí)的態(tài)度回來后把題目都上機(jī)試驗(yàn)了下，結(jié)果一下就悲劇了，錯(cuò)的體無完服啊。。。
總結(jié)了一下：
   1。認(rèn)真對(duì)待，不要小看了筆試題目：做題的時(shí)候心想這些筆試題目都很簡(jiǎn)單啊，很多題目都是掃了一眼就立即寫出了答案，結(jié)果回來后才發(fā)現(xiàn)這些題目都設(shè)置了陷阱，讓你掉進(jìn)去就出不來了。
   2。C＋＋基礎(chǔ)不夠扎實(shí)。枉我還一天到晚的研究C＋＋的高級(jí)特性，結(jié)果很多基礎(chǔ)的知識(shí)卻都是一知半解。
特將此次筆試的一些心得和體會(huì)記錄于此，好提醒自己。下面主要分析幾個(gè)我做錯(cuò)的題目。題目并非與原題完全一致。
題目一：

請(qǐng)說出上述語句的執(zhí)行結(jié)果。
很多人看過這段代碼后估計(jì)都會(huì)直接就寫上了 16 10 6 這樣的結(jié)果吧，但上機(jī)實(shí)驗(yàn)的輸出結(jié)果是： 18 10 6
為什么會(huì)出現(xiàn)這樣的結(jié)果，下面是我的分析過程，如果有不對(duì)的地方請(qǐng)大家指正。
為了跟蹤代碼的執(zhí)行步驟，我設(shè)計(jì)了一個(gè)類X，這個(gè)類是對(duì)int的模擬，行為方面與int基本一致，除了會(huì)打印出一些幫助我們理解的信息，代碼如下：


然后執(zhí)行以下代碼：


使用GCC4。5編譯后，代碼的執(zhí)行結(jié)果如下：

首先，BOOST中有4種有關(guān)互斥量得概念。
1.LOCKABLE :僅支持排它型所有權(quán)
2.TIMEDLOCKABLE：支持帶超時(shí)的排它型所有權(quán)
3.SHAREDLOCKABLE： 支持帶超時(shí)的排他型所有權(quán)和共享型所有權(quán)（讀寫鎖）
4.UPGRADELOCKABLE： 支持帶超時(shí)的排他型所有權(quán)和共享型所有權(quán)，以及共享型所有權(quán)升級(jí)為排他型所有權(quán)（升級(jí)過程阻塞）(也支持降級(jí))

可以看到2強(qiáng)化自1,3強(qiáng)化自2.4強(qiáng)化自3，支持某一概念則一定支持其強(qiáng)化自的概念。

boost::mutex 實(shí)現(xiàn)了LOCKABLE概念 （boost::recursive_mutex 是其遞歸鎖的版本）
boost::timed_mutex 實(shí)現(xiàn)了TIMEDLOCKABLE概念 （boost::recursive_timed_mutex 是其遞歸鎖的版本）
boost::shared_mutex實(shí)現(xiàn)了SHAREDLOCKABLE概念
boost::shared_mutex同樣實(shí)現(xiàn)了UPGRADELOCKABLE概念

出于提供RAII操作風(fēng)格和安全等其他一些原因BOOST不希望用戶直接調(diào)用各種MUTEX類型中的相關(guān)接口，而是通過它提供的一些LOCK_TYPE來幫助我們調(diào)用。

主要的LOCK_TYPE包括：

boost::unique_lock<LOCKABLE> 針對(duì)支持LOCKABLE概念的類型（上述4中MUTEX類型都支持LOCKABLE概念）。以RAII的方式調(diào)用該類的lock() （調(diào)用成功后排它的獨(dú)占該互斥量）和 unlock() 方法。

boost::shared_lock<SHAREDLOCKABLE>針對(duì)支持SHAREDLOCKABLE概念的類型，boost::shared_mutex實(shí)現(xiàn)了該概念，注意，支持SHAREDLOCKABLE概念的類既支持排他的獨(dú)占（寫鎖，通過調(diào)用lock unlock系列函數(shù)），也支持共享的方式占用（讀鎖，通過調(diào)用lock_shared系列），shared_lock默認(rèn)調(diào)用lock_shared系列。

最主要最常用的就是上面這兩個(gè)LOCK類型，分別代表獨(dú)占方式和共享方式，其他的就不一一分析了。

下面是個(gè)從http://hi.baidu.com/jrckkyy/blog/item/d7ccb508dfba2e3ce8248817.html此處找到的例子