問題タブ [countdownlatch]

課題で、「ping」と「pong」を正しく (ping の前に pong がないことを意味する) 10 回呼び出すピンポン ゲームを実装するように要求されました。つまり、コンソールの最終的な出力は、「ping!(1)」、「pong!(1)」、「ping!(2)」、「pong!(2)」などになります。

要求は、セマフォ、reetrantlock、およびカウントダウン ラッチを備えた gamepingpongthread を実装することです。

私の問題は、印刷順序が必ずしも要求どおりではないことです。何が間違っているのだろうかと思います。

コードは次のとおりです。

前もって感謝します

私は2つのParse.comクエリを作成していました..

そして私は本質的にこれをやろうとしました、

もちろん、私は雑多なエラーIllegalMonitorStateException: object not locked by thread before wait()などを取得します。

私が密集していること以外の問題の一部は、Parse の findInBackground へのこれらの呼び出しが、とにかく新しいスレッドであなたを離陸させることですよね?

記録のために、これらの Parse 呼び出しの 1 つが次のようになります。

そしてそのドコ…

http://parse.com/docs/android/api/com/parse/ParseQuery.html#findInBackground(com.parse.FindCallback)

CountDownLatch以下は、これらのマップで書き込みが発生するたびに、プライマリ、セカンダリ、およびターシャリ マップで初めて読み取りが発生しないようにするために使用するクラスです。

以下は、3 つのマップすべての設定のみを担当するバックグラウンド スレッド クラスです(以下の parseResponse メソッドを探してください)。10分おきに運行しています。

問題文：

マッピング オブジェクトとプライマリ、セカンダリ、およびターシャリ マップに対してあらゆる種類の null チェックまたはサニティ チェックを実行すると、パフォーマンスが大幅に低下します (理由は不明です)。しかし、健全性チェックや null チェックを行わなければ、パフォーマンスは非常に良くなります。誰が何が間違っているのか、なぜそれが起こるのか説明できますか?

以下は例です -

ClientDataメインスレッドですべてのマッピングを取得するためにクラスを使用しています。mappings以下に示すように、 、mappings.primary、mappings.secondaryおよびmappings.tertiaryが空でないことを確認するために、あらゆる種類の健全性チェックを行っています。それらが空の場合、エラーをログに記録して戻ります

1 次、2 次、および 3 次マッピングに対する上記のサニティーおよびヌル・チェックにより、アプリケーションの全体的なパフォーマンス (95 パーセンタイル) は 4 ミリ秒になります。

しかし、1 次、2 次、および 3 次マッピングのサニティー・チェックまたはヌル・チェックなしでこのようにすると、全体的なパフォーマンス (95 パーセンタイル) は 0.87 ミリ秒になります。

以下は私の isEmpty と isNotEmpty メソッドです -

明示的にリリースする方法はありますかCountDownLatch- do なしを意味しますcountDown()。

例: 100 個のスレッドが実行されるのを待っているとしますcountDown()が、何かが失敗した場合、これ以上待たずにこのラッチを解放したいとします。getCount()ラッチをオンにしてからサイクルを実行することを考えていましcountDown()たが、最適な方法ではありません。

提案/アイデアはありますか？

Java では、CountdownLatch が状態 = 0 に達すると変更できないため、永久に開いたままになります。なぜ実装者は CountDownLatch の再利用を許可しないのだろうか?

非ブロッキング FusedLocationProvider API をブロッキング API として使用しようとしています。これが私がやっていることです（大まかに）：

1. AsyncTask を開始する
2. バックグラウンド スレッドで、PlayServices/FusedProvider API に接続します。これに使用できるタイムアウト付きのブロック方法があります。
3. 上記の API を使用して、場所の更新をリクエストします。API は、デバイスを使用して位置を計算し、呼び出し元のスレッドで実行されるコールバックをトリガーします。
4. を使用してコールバックを待ちますcountDownLatch.await(timeOut,timeUnit)
5. Fused API がコールバックをトリガーし、場所を取得して を実行するとcountDownLatch.countdown()、ラッチが解放されます。
6. 場所を返します。

いつでも場所を計算して操作する必要がある可能性があるため、ブロックする方法が必要です。上記のアプローチは機能していますが、ブロックしている同じスレッドから CountDownLatch がトリガーされているため、より良い方法を探しています。これを行うことで冒涜/完全なダンベリーを犯しているかどうかはわかりません。

これが私のコードです：

この場合、無限ループのラッチとブロックするフラグ以外に戦略はありますか? ありがとう。