問題タブ [manualresetevent]

空でないコンストラクターを持つシングルトンを作成し、同期した方法でアクセスしようとしています。コンポーネントの初期化の順序を制御できないため、コンポーネントが初期化される前にシングルトンにアクセスする場合は、次のようにする必要があります。待つ。

ファクトリメソッドが1回だけ呼び出され、初期化フェーズで例外がスローされます

[OnWorkerThread]は、ファクトリをワーカースレッドで実行するための属性であり、ファクトリは1回だけ呼び出されます。

myappを起動すると、次のようになることがあります。

例外ソース：mscorlib例外タイプ：System.Runtime.InteropServices.SEHException例外メッセージ：外部コンポーネントが例外をスローしました。例外ターゲットサイト：WaitOneNative

----スタックトレース----System.Threading.WaitHandle.WaitOneNative（waitableSafeHandle As SafeHandle、msilesTimeout As UInt32、hasThreadAffinity As Boolean、exitContext As Boolean）AddinExpress.RTD.2005.dll：N 00000（0x0）JITシステム。 Threading.WaitHandle.InternalWaitOne（waitableSafeHandle As SafeHandle、msilsTimeout As Int64、hasThreadAffinity As Boolean、exitContext As Boolean）AddinExpress.RTD.2005.dll：N 0020（0x14）IL System.Threading.WaitHandle.WaitOne（millisecondsTimeout As Int32、exitContextブール値）

私は何が間違っていますか？

タイムアウトパラメータを指定したManualResetEventクラスの使用に問題があります。この問題は、特にWinXP組み込みプラットフォームで発生します。このコードは、他のWindowsプラットフォームでも完全に機能します。TCPサーバーと通信しています。私のクライアントコードでは、サーバーに接続して新しいスレッドを生成します。これは、受信ソケットのデータを継続的に監視することです。メインスレッドでデータを送信します。コードスニペットは以下に添付されています：

コードの重要な側面を強調しました。ほとんどのWindowsOSで、WaitOne（timeout）関数が問題なく機能することが確認されています。しかし、XP組み込みでは、問題が発生します。WaitOneは、受信スレッドからデータを受信せずに、ほとんどすぐに戻ります。

私がしたことは、WaitOneに-1を渡すことによって、タイムアウトをINFINITEにしたことです。この場合、私は問題を解決することができました。ただし、これにより他の副作用が発生します（たとえば、サーバーがシャットダウンされた場合、WaitOneが戻ることはありません！）

誰かがこの問題を解決するのを手伝ってくれませんか？

(別のプロジェクトで) クラス メソッドを実行するコンソール アプリがあります。このメソッドは、Web サービスへの POST を非同期的に実行し (これは 3 分間の長い操作です)、POST の影響を受けたレコードの数を返すコールバックを持っています。その間、プログラムは 3 分もかからない他のことを続け、プログラムはコールバックが戻る前に終了します。

過去に、完了を防ぐために以下に示すように ManualResetEvent を使用しましたが、この場合、私のメソッドは別のクラス ライブラリにあり、できるだけクリーンに保ちたいと考えています。

呼び出されたクラスを実行フラグで汚染することなく、これを達成するためのクリーンなパターンを考え出す手助けをいただければ幸いです。

私はobjective-cでsshラッパーを書いていますが、コマンドの実行に必要なmaxTimeを実装しようとしています。私がそれを実装する方法は次のとおりです。

メインスレッド：

1. タイムアウトを計算する
2. コマンドを実行して返されたデータを解析するためのasyncThread（GCDキュー）を作成します
3. waitForTimeoutOrSignal
4. 結果を返す

AsyncThread：

1. コマンドを実行する
2. 返されたデータを取得する
3. 正しいデータ信号を受信した場合MainThread

C＃では、ManualResetEventsを使用してMainThreadに信号を送ることに成功しました。Objective-Cで私が見つけることができる最も近いクラスはNSConditionですが、スレッド間通信用に構築されていないようです。

実際、私は次のようになります。

2012-05-22 00：31：05.761 libssh2-for-iOS [60821：11303] **-[NSConditionunlock]：条件（'（null）'）がロックされなかったスレッドからロック解除されました

2012-05-22 00：31：05.763 libssh2-for-iOS [60821：11303] **デバッグするには_NSLockError（）を中断します。

使ってみると。NSConditionを使用する別の方法、またはスレッドが何らかの信号を受信するまでスリープするためのより良い方法はありますか？

MSDN のAsynchronous Client Socketコード サンプルを利用して、家庭用機器を接続および制御しようとしています。私が理解しているように、サンプル コードのReceiveCallbackメソッドは、EventWaitHandle ManualResetEventのインスタンスとreceiveDone.WaitOne()メソッドを使用して、ソケットのすべてのデータがリモート デバイスから送信されたというシグナルをスレッドが受信するまで、現在のスレッドの処理を保留します。 . ソケットのすべてのデータが送信された後 (ソケットのデータが空で、bytesRead = 0 )、 Waithandle が削除され、アプリケーションは処理を続行します。

残念ながら、コードの実行をステップスルーすると、最後にクライアントがリモート デバイスからデータを返した後、データ キューが空 (つまり、bytesRead = 0) かどうかを確認するためにReceiveCallbackが返されないように見えます。 ManualResetEventの状態がリセットされ、アプリケーションが処理を続行する場合に、 ReceiveCallbackで「else」条件に入ることはありません。したがって、「else」条件に入ることはないため、ManualResetEventはリセットされず、アプリケーションはフリーズします。

コードから "receiveDone.WaitOne()" メソッドを削除することはできますが、すべてのデータが受信されたというManualResetEvent の通知を待たずに実行を許可します。これは、通常は不完全な機器からのデータ文字列を返します。

このコード サンプルの使い方は間違っていますか? 誰かがこれを以前に見たことがありますか、またはこの問題を回避する方法について何か経験がありましたか?

2012 年 7 月 14 日 - 更新: MSDN のAsynchronous Client Socket Exampleをさらにテストした結果、ReceiveCallbackが実際にポートを再ポーリングし、"bytesRead = 0" 条件が満たされるのはソケットが解放されたとき(クライアント. Shutdown(SocketShutdown.Both); client.Close(); )。これを正しく理解している場合、これは、 receiveDone.WaitOne() メソッドを通過するには接続を閉じる必要があることを意味します。WaitOne() Waithandle を満たすために接続が閉じられた場合、接続を開いたままにして、アプリケーションが継続的に発生する機器の更新をリッスンできるようにすることを望んでいたという点で、アプリケーションの目的を完全に無効にします。

2012 年 7月 16 日 - 更新:マイクロソフト テクニカル サポートに返信したところ、「この問題について調査を行っています。ご連絡するまでに時間がかかる場合があります。」 そのため、現時点では、このコードを操作することでこの問題を解決できるとは思えません。

非同期通信手順を記述するための基盤として非同期クライアント ソケットのサンプル コードが利用できないため、より信頼性の高い代替ルーチンを提案できる人がいるかどうか尋ねてもよろしいですか? 3 つの機器があり、それぞれに独自の IP アドレスとポート番号があります。したがって、デバイスごとにインスタンスを作成できるクラスを利用できれば理想的です。さらに、機器から継続的に送信される自発的な更新を受信するには、ポートを開いたままにしておく必要があります。最後に、更新には、メッセージの送信が完了したことを知らせる終了文字または定義された長さがありません。したがって、ルーチンは、使用可能なデータについてポートを継続的にポーリングする必要があります。 アドバイスや提案をいただければ幸いです。

2012 年 7 月 18 日 - 回避策: MSDN の Asynchronous Client Socketコード サンプルを機能させるためにかなりの時間を費やした後、プログラムによってデバイスの応答が継続的に認識されるようにするには、別の場所を探す必要があることが明らかになりました。他の誰かの脳の損傷を救うことを期待して、私が使用した回避策を含めましたが、これはこの時点でうまく機能しているようです. 誰か提案があれば、遠慮なくこの質問に追加してください!

これは私が使用した回避策です：

および GC_Interface クラス:

まず、これは次のスレッドの複製としてタグ付けされている可能性があります: HttpWebRequest.BeginGetResponse が Windows Phone 7で終了するのを待ちますが、そのスレッドの応答は問題を解決するのに役立ちませんでした。

まず、アプリケーションの登録を処理するために UI スレッドでユーザー データを収集しています。ここには、ManualResetEvent のインスタンスもあります。

登録プロセスを処理する別のスレッドがあります (HttpWebRequest.BeginGetResponse() とそれに対応するコールバック メソッドが含まれます)。

この呼び出しの直後に、次の呼び出しで現在の (UI) スレッドをブロックします。

登録プロセスを処理するスレッドが開始したら、HttpWebRequest をインスタンス化し、BeginGetResponse() メソッドを呼び出します。

問題は、コールバック メソッド (以下のコード) が呼び出されず、アプリケーションがフリーズすることです。また、スローされる例外もないようです。

理想的には、コールバック メソッドの実行が終了した後、アプリケーションを httpSessionCompleted() から続行したいと考えています。誰かがガイダンス/提案を手伝ってくれますか?

冗長で申し訳ありません。ありがとう！

私のプログラムには複数のスレッドが含まれており、単一の ManualResetEvent オブジェクトを使用して制御したいと考えています。新しいオブジェクトを作成するとき (例: new ManualResetEvent MRE = new ManualResetEvent(args);)、すべてのクラスから MRE にアクセスできるようにしたいのですが、パラメータとして常に渡すのは面倒です。静的にしたほうがいいでしょうか？または、より効率的な方法はありますか？-ありがとう

内部サービスから取得したデータを保持するために単純なキャッシュを使用するクラスを実装しようとしています。ManualResetEventを使用して、キャッシュされたデータを最初のスレッドと同時に更新しようとする複数のスレッドをブロックし、Set（）を呼び出してからReset（）を呼び出して、データが取得されたら他のスレッドに続行するように通知します。テストすると、すべてのスレッドが解放される場合と、1つ以上が解放されない場合があり、すべてのスレッドが解放される前にリセットを呼び出しているかのように、タイムアウトすることがあります。誰かが私が間違っていることを説明できますか？

以下のコードの縮小版を含めました。

ManualResetEvent または同期プリミティブ (モニターなど) を使用してイベントやロックを待機する方法は知っていますが、次のようなものを実装する方法があるかどうか疑問に思っています。

1) イベント X が発生するまで 1000ms 待ちます

2) 1000ms以内にイベントが発生した場合、パスAを実行

3) それ以外の場合は、パス B を実行します。

これは基本的に条件付きの待機関数であり、条件は待機時間です。可能であれば、それを実装する最良の方法は何でしょうか?