0

リソース プールのコンテキストで ReentrantLock の条件をいじっています。スレッド通信が簡素化されていることがわかります。私の質問は、私は、acquiratedMapEmpty、freeQueueNotEmpty、待機中の変更、単一の異なるものなどの奇妙な条件を有機的に書くことになるということです。技術的には、それらはすべて 1 つの条件付きで置き換えることも、複数の条件付きに分割することもできます。経験則は次のとおりです。

  1. 条件の識別
  2. 多すぎるか少なすぎるかを把握する
  3. 正しい軌道に乗っているとき、またはコースから外れているとき

リソースを削除する例を次に示します。

 public boolean remove(R resource) throws InterruptedException {

    System.out.println("Remove, resource: " + resource + " with thread: " + Thread.currentThread().getName());
    if (resource == null) {
        throw new NullPointerException();
    }
    mainLock.lock();
    try {
        if (!isOpen) {
            throw new IllegalStateException("Not open");
        }
        Object lock = locks.get(resource);
        if (lock == null) {
            return false;
        }
        if (freeQueue.remove(resource)) {
            locks.remove(resource);
            if (!freeQueue.isEmpty()) {
                freeQueueNotEmpty.signalAll();
            }
            return true;
        }
        while (!freeQueue.contains(resource)) {
            change.await();
            if (!isOpen) {
                throw new IllegalStateException("Not open");
            }
            lock = locks.get(resource);
            if (lock == null) {
                return false;
            }
        }
        if (freeQueue.remove(resource)) {
            locks.remove(resource);
            if (!freeQueue.isEmpty()) {
                freeQueueNotEmpty.signalAll();
            }
            return true;
        }
        return false;
    } finally {
        mainLock.unlock();
    }
}
4

2 に答える 2

1

私の謙虚な意見では、ここには経験則はありません。
それはユースケースに大きく依存し、同期は簡単なトピックではありません。もちろん、システムをロックで「使い果たす」べきではありません。ロックは高価なリソースです。
スレッドを調整し、共有リソースを保護する必要がある場合は、同期オブジェクトを使用するしかありません。
ロックやロックから取得される条件などの同期オブジェクトを使用するたびに、ユースケースは何か、ロックが本当に必要か、他にどのスレッドを調整する必要があるかを自問する必要があります。流れ）。
この質問を少し話題から外して、例を挙げたいと思います-同期キーワードを使用するいくつかのスレッドがあることを発見しました。
しかし、一部は読み取りを実行し、一部は書き込みを実行するため、ReaderWriterLock に切り替えました-
あなたの場合も
そうです。すべての種類の同期オブジェクトをクールな理由だけで使用しないでください-それらが本当に必要かどうか、そしてどこで必要かを慎重に理解してください。

于 2012-11-20T06:28:56.083 に答える
1

経験則として、スレッドがブロックされる理由と同じ数の条件変数を持つ傾向があります。理論的根拠は、条件変数にシグナルを送るとき、シグナルしている状態の特定の変化を待っているスレッドをウェイクアップしたいということです。そして、本当に、本当に「群れの群れ」症候群を回避したい -すべてのスレッドをウェイクアップするある条件でブロックされたスレッドのうちの1 つだけが進行し、他のスレッドはすべてスリープ状態に戻り、その間に貴重な CPU 時間を浪費し、キャッシュをスラッシングしました。

于 2012-11-20T23:28:18.250 に答える