問題タブ [reentrantlock]

私が持っているとしましょうReentrantLock、

barそして、ロックを使用する方法、

また、ロックを使用するメソッドを呼び出しmethodOneます。methodTwo

bar電話をかける前にロックを解除したほうがいいmethodOneですか？一般に、別のメソッドを呼び出す前にロックを解除することをお勧めしますか？

synchronizedミューテックスのようなものを扱うためにJavaで使用されます。ただし、 Java のLockようなインターフェースの実装ではReentrantLock、このキーワードは使用されません。すべてのコードは通常のコードに見えます。では、地球上の複数のスレッドをどのように処理するのでしょうか?

次のコードが関連していると思います。

のtryAcquireメソッドSync_ReentrantLock

SyncextendsAbstractQueuedSynchronizerと関連するコード:

キーワードが使用されていないsynchronizedようですが、どのようにミューテックスを保証しますか?

Java 7では、DelayQueueの実装は公平性ポリシーなしでReentrantLockを使用します。これは長期的には問題ですか？このためにスレッドが飢える可能性はありますか？

ありがとう

私は次のコードを持っていますが、それは私に多くの問題を引き起こしています.私はそれをあまりにも長く見つめていたと思います.

メソッドの呼び出し - (RobotInterface クラス内)

TwoWaySerialCommTest クラス - rxtx Web サイトの例から適応。参照用の完全なコード。重要な部分は put() メソッドとシリアルライターです。

出力を以下に示します。ロックファイルを移動したり、シリアルライターからロックを外したり、呼び出しメソッドにロックを入れたり、その他のハックを試みました。

望ましい結果は、メソッドが serialConnection(接続された TwoWaySerialCommTest のインスタンス) を呼び出し、serialConnection がシリアル ポートに書き込み、応答を受信するのを待ってから実行を継続することです。

私はこれで何時間も頭を悩ませてきました。助けてください:)

提案されているように、通知をtryブロック内に移動すると、出力は次のようになります

RobotInterface クラス -

}

新しい条件を作成chopstickFreeし、pickUpChopstick()メソッドでロックを待っていますが、まったくアクセスできません。

デバッグを通じて、メソッドのchopstickFree.await()行に到達すると、無期限に一時停止することがわかりましたpickUpChopstick()

理解できない？コンストラクターのそのコードは、それを機能させるための不確かな試みでしたが、いずれにせよ、新しい条件を作成し、それが解放されていることをすべての人に通知しましたが、まったくロックできませんか?

何か案は？

乾杯

複数のスレッドのロックを管理する LockManager があります。スレッドが悪い子である場合があり、それらを強制終了し、LockManager にすべてのロックを解放するように依頼する必要があります。しかし、Java で ReentrantLock を使用しているため、これは不可能であり、別のスレッドが所有するロックを解除することはできません。

ロックを使用せざるを得ません (セマフォは使用できません。これは宿題です)。他のスレッドが所有するロックを解除できる Java Lock の実装はありますか?

これまでのところ、私が検討したオプションは次のとおりです。

• これを可能にする方法で ReentrantLock を再実装する
• セマフォとリエントラントロックの間である種のマッピングを行う

あなたが役に立つかもしれない追加の情報源:

• 再入可能ロック - 別のスレッドからのロック解除
• ロックを所有していないスレッドからロックを解除するか、これを回避するために再設計しますか?

ReentrantLocksデッドロックを防ぐために、スレッドがより高い ID のロックを取得する前に、より低い ID のロックを取得する必要がある、一意の整数 ID を持つ一連のラップがあります。3 つのロック (lock0、lock1、および lock2) は、より高い ID を持つロックよりも優先度が高く、他のすべてのロックの優先度は同じです。つまり、スレッドがこれら 3 つの優先度の高いロックのいずれかを取得すると、必要な優先度の低いロックを保持している他のスレッドを中断する必要があります。たとえば、スレッド 1 はロック 4 とロック 5 を保持しており、スレッド 0 はロック 0 を保持しており、ロック 4 とロック 5 を必要としているため、スレッド 0 はスレッド 1 に割り込みlockInterruptiblyますisInterruptedメソッド) を取得し、そのロックを取得します。Thread1 は、Thread0 から通知されるまで待機します (つまり、Thread0 がロックを終了するまで、ロックを再取得しようとはしません)。

これは、いくつかの理由で理想的ではありません。理想的には、Thread1 が Thread0 の割り込みを処理している間、他のスレッドが先にジャンプしてロックを取得しないように、Thread0 がすぐにロックが必要であることを通知するようにします (つまり、Thread0 は待機中のスレッドのキューに入り、Thread2 が試行した場合Thread0 が Thread1 に割り込んでいる間にロックを取得するには、Thread0 が Thread2 の前にロックを取得します) - たとえば、tryLock別のスレッドがロックを保持している場合に、そのスレッドをロックのキューに追加するバリアント。また、現在、ロック 4 またはロック 5 でキューに入れられたスレッドがある場合、スレッド 0 はそれらがロックを取得するのを待ってからそれらを中断する必要があります。スレッドは優先度の高いロックを保持していました)。lockInterruptibly最後に、スレッド 1がすべてのロックを放棄する必要はありません。中断されたときにすべてのロックを放棄します(スレッドがロックの取得を待機している間に中断されたと仮定します)。

車輪を再発明する前に、これらの要件の一部またはすべて、または何らかの種類を既に実装しているロック クラスがあるかどうか疑問に思っていましたPriorityReentrantLock。私は を見て、自分のニーズを満たすためにそれを変更するのにあまり多くの作業をAbstractQueuedSynchronizer必要としないとは思いません(特に優先度が 2 つしか必要ないため)。より良い。