問題タブ [waitformultipleobjects]

Win32 APIを使用して、stdin / stdoutをシリアルポート（ある種のコマンドラインターミナルエミュレーター）にマップする小さなユーティリティを作成しようとしています。私は次のコードを持っていますが、これは機能するはずですが、シリアルポートから通知を正しく受信していないようです。

私がここで間違っていることについて何か考えはありますか？

言葉の問題：

私のアプリケーションでは、シリアルポートから読み取るクラスがあります。これは、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の待機との間に常にギャップがあることを意味します。これにより、スレッドがハングします。

誰かがこの問題の解決策を知っていますか？

コードの問題：

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

Windows 用の C++ のコードがいくつかあり、それを Java に移植する予定です。しかし、残念ながら思ったほど簡単ではありません。誰か助けてくれませんか？

アルゴリズムを見てください：

hDataAvailabeEvent は、異なるスレッドから設定できます。すべてのデータが処理されると、イベントがリセットされ、WaitForMultipleObjects の呼び出し時にスレッドは、新しいデータが到着するか、スレッドが終了するまで中断されます。

Java で Waitformultipleobjectsという質問を既に見ましたが、1 サイクルの反復ですべての新しいデータを処理できず、処理がいくつかの反復に広がるため、私の状況には適していません。

前もって感謝します！

この質問に基づいて、Poco::NamedEvent を使用しますが、複数のイベント (win32 WaitForMultipleObjects() など) を待つ必要があります。

ポコにそんなのありますか？（ドキュメントを検索してもあまり得られませんが、おそらく正しい検索を使用していません）

小さなtcpチャットサーバーで書いていますが、「エレガントに」解決する方法がわからない問題がいくつか発生しています。

以下は私のメインループのコードです：それは次のとおりです：
1。新しいtcp接続が確立されると、フラグが立てられた基本イベントでベクターを開始します。
2.この接続を取得し、それをベクトルにプッシュバックします。次に、ソケットを使用してCSingleConnectionオブジェクトを作成し、ソケットをそのオブジェクトに渡します。
2.1。接続がデータを受信したときにフラグが立てられるCSingleConnectionからイベントを取得します...
3。データを受信したとき。待機がいっぱいになり、配列内のハンドルの数が返されます...他のすべてのベクトルを使用すると、現在送信しているベクトルを判別できるようです...

しかし、誰もが理解できるように、この方法論は本当に不十分です...接続ソケットを取得したり、単一の接続を作成したりするなど、これらすべてをより適切に行う方法がわかりません：/ ...

提案、改善などはありますか？...

WFMOによって通知されたイベントを処理しますが、この時点でさらにN回通知されています。WFMOは1回またはN回戻りますか？

シングル スレッド アパートメントを必要とする COM オブジェクトを作成するスレッドがあります。

もともと、このスレッドのメイン関数は、WaitForMultipleObjects ループに入れていました。COM メッセージ ポンプが本来の役割を果たせなくなるため、これは明らかに問題です。

解決策としてこれを MsgWaitForMultipleObjects に置き換えましたが、現在問題が発生しています。

このコードは、処理を続行して MsgWaitForMultipleObjects を再度呼び出すことで、WAIT_FAILED の戻り値を処理します。MsgWaitForMultipleObjects を呼び出すと、WAIT_FAILED が数回返されることがあります (私が見た中で最も多かったのは 9 回です) が、突然問題なく動作します。

このコードは、関数が正当な理由で WAIT_FAILED を返した場合に無限ループに陥る可能性があるように記述されています。これを修正する必要があることはわかっていますが、MsgWaitForMultipleObjects 呼び出しが最終的に成功するため、現時点では「回避策」と考えています。

このコードは、Windows 7、Vista、および XP (すべて 32 ビット、Windows 7 32 ビットおよび 64 ビット) でテストされています。

なぜこれが起こっているのか誰にも分かりますか？

関連するコード:

出力例は次のとおりです。

WAIT_FAILED の戻り値は、メッセージによって待機が中断された後にのみ発生していると思います。

私は10以上のスレッドを作成するWindowsサービスを持っています:

• ジョブを実行してから、再開されるまで WaitForMultipleObjects 状態に入ります..
• 各スレッドは、その AppServer で TDCOMConnection コンポーネント呼び出しメソッドを作成し、接続を閉じます

サービスは問題なく動作しますが、メモリ リークの問題が発生しています。

その問題がメッセージのポンピングに関連している可能性があるかどうか、私はただ興味があります.

STA スレッドでのメッセージ ポンピングは、com マーシャリングを使用する場合にのみ適用する必要があると常に考えていました (2 つのスレッド間にプロキシがある状況で)。

しかし、今日、電話をブロックする場合はメッセージを処理する必要があることをどこかで読みました。本当？

ただし、私のアプリケーションは引き続き正しく機能し、それ自体をブロックしません...

たぶん、WaitForMultipleObjects の代わりに CoWaitForMultipleHandles を使用する必要がありますか?

この問題について何か考えはありますか？

ミューテックスを使用してグローバルダブルを保護する例に取り組んでいますが、エラーが発生します-

Lab7.exe の 0x77b6308e で未処理の例外: 0xC0000005: アクセス違反の書き込み場所 0x00000068。

これはスコアへのアクセスに関連していると思いますか？(グローバルダブル)

アップデート：

ループが 10 ではなく 1000 に設定されている問題を修正した後もエラーが発生しましたが、ミューテックスを参照するコードをコメントアウトしたところ、エラーは発生しませんでした。

更新 2

慣習に従って、スレッドは 0 を返します (長い 1 週間でした!)

私はミューテックス関連のコードを追加しようとしましたが、CRITICAL_SECTION、InitializeCriticalSection、およびDeleteCriticalSectionがすべて追加された状態で、プログラムはコンパイルされて正常に実行されます(もちろんダブルの競合状態の問題を除く)。問題はEnterCriticalSectionにあるようですまたは LeaveCriticalSection を追加するとエラーが再発するためです。

多くの異なる IO デバイスによって制御される HANDLE のリストがあります。次の（パフォーマンス）違いは何ですか：

1. これらすべてのハンドルに対する WaitForMultipleObjects の呼び出し
2. これらすべてのハンドルの周りのboost::windows::basic_handleのasync_read

WaitForMultipleObjects O(n) 時間は n ハンドルの量で複雑ですか?
どういうわけか、windows::basic_handle で async_read を呼び出すことができますよね? それともその仮定は間違っていますか？
複数のスレッドで同じ IO デバイスで run を呼び出した場合、ハンドリング呼び出しはそれらのスレッド間でバランスが取れますか? これは asio を使用する大きなメリットです。