Boost.ThreadのCEvent風の動作

Question

単語の問題：

私のアプリケーションでは、シリアルポートから読み込むクラスがあります。 COMポート処理にWindowsプリミティブを使用し、非同期読み取り用のスレッドを持っていました。私はこれをBoost.AsioやBoost.ThreadのようなBoostライブラリを使ってWindowsプリミティブから変換しようとしています。

私のIOスレッドには、それぞれがメッセージを表すいくつかのMFC CEvent変数がありました：読み取り要求、書き込み要求、読み取り完了、書き込み完了、IOキャンセル。これらはWaitForMultipleObjectsで待っていました。

問題は、Boost.ThreadにはCEventとWaitForMultipleObjectsのどちらのアナログもないようです。私が一番近いのは、これらを破棄してイベントをブール値のセットに置き換え、ブール値が変更されたときに呼び出されるnotify_all（）関数を持つcondition_variableを使用することです。

しかし、boost :: condition_variableは、CEventとは1つの批判的な点で異なります.CEventが待機していない間に通知された場合、すぐ次の待機が成功します。 boost :: condition_variableでは、待機していなければ通知関数は無視されます。

これは、フラグのチェックと通知を失う可能性のあるcondition_variableを待つ間に常にギャップがあることを意味します。これにより、スレッドがハングします。

この問題の解決策を知っている人はいますか？コード内

問題：

// Old IO Thread 
CEvent msg_cancel; 
CEvent msg_read_req; 
CEvent msg_write_req; 
CEvent msg_read_comp; 
CEvent msg_write_comp; 

CEvent events[] = { 
    msg_cancel, 
    msg_read_req, 
    msg_write_req, 
    msg_read_comp, 
    msg_write_comp 
}; 

bool cancel = false; 

while (!cancel) 
{ 
    switch(WaitForMultipleObjects(5, events, false, INFINITE)) 
    { 
     case WAIT_OBJECT_0 : 
      // msg_cancel 
      cancel = true; 
      break; 

     ... 
    } 
} 

Boost.Threadにそれをエミュレートする方法は？

Answer 1

あなたが言ったように、Windowsスタイルのイベントに似せるには、条件変数とブール値フラグが必要です。もちろん、複数のブール値フラグを組み合わせて1つのフラグにすることもできます。

しかし、あなたが言及した問題は、（条件変数は、待ち時間がすぐに戻りますactive状態を取得することはありません）通常はそのように解決されるmutexがでロックが解除されるまで待機するために、第2のスレッドを持つことにより

condition-variable 
mutex 

main-thread: 
    lock(mutex) { start condition-signaling-thread } 
    while(some predicate) { 
    condition-variable.wait(mutex) 
    do-stuff 
    } 

condition-signaling-thread: 
    loop:  
    lock(mutex) { 
     do-whatever 
    } 
    condition-variable.notify(); 

を条件を処理するスレッドによって、各条件が確実に処理されます。 （注：Javaではnotify（）メソッドをロック内で呼び出す必要があります。実装の詳細によっては、C++で実行するとパフォーマンスが低下する可能性がありますが、プログラマが少なくとも一度、受信機との状態の発射）。

boost.threadがwindowsスタイルのイベント（およびposix-semaphores、btw）を提供しないのは、それらのプリミティブが非常に簡単にねじれてしまうからです。アプリケーションを別のプラットフォームに移植する予定がない場合、アプリケーションをこの異なるスタイルに適応させることは価値がないかもしれません。