3

言葉の問題：

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

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

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

ただし、boost :: condition_variableは、CEventとは重要な点で異なります。待機していないときに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でそれをエミュレートする方法は？

4

1 に答える 1

3

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

ただし、前述の問題（条件変数はactive、待機がすぐに戻る状態になることはありません）は、通常、次のようにして解決されます。

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();

条件を処理するスレッドによってミューテックスのロックが解除されるまで2番目のスレッドを待機させることにより、各条件が確実に処理されるようにすることができます。（注：Javaでは、notify（）メソッドをロック内で呼び出す必要があります。これは、実装の詳細によっては、C ++で実行するとパフォーマンスが低下する可能性がありますが、プログラマーが同期する方法について少なくとも1回は考えていることを確認します。受信機での条件の発火）。

boost.threadがウィンドウスタイルのイベント（およびposix-semaphores、ところで）を提供しない理由は、これらのプリミティブが非常に簡単に失敗するためです。アプリケーションを別のプラットフォームに移植する予定がない場合は、アプリケーションをこの異なるスタイルに適合させる価値がない可能性があります。

于 2009-08-30T15:29:46.683 に答える