Есть ли не реентерабельный ReadWriteLock, который я могу использовать?

Question

Мне нужен ReadWriteLock, который НЕ реентерабелен, потому что блокировка может быть выпущена другим потоком, чем тот, который его приобрел. (Я понял это, когда я начал периодически прерывать IllegalMonitorStateException.)

Я не уверен, что нереферентом является правильный термин. ReentrantLock позволяет потоку, который в настоящее время удерживает, блокировать, чтобы снова получить его. Я НЕ хочу этого поведения, поэтому я называю его «неретеррантным».

Контекст заключается в том, что у меня есть сервер сокетов с использованием пула потоков. В каждом соединении нет нити. Запросы могут обрабатываться различными потоками. Клиентскому соединению может потребоваться блокировка в одном запросе и разблокировка в другом запросе. Поскольку запросы могут обрабатываться разными потоками, я должен иметь возможность блокировки и разблокировки в разных потоках.

Предположим ради этого вопроса, что мне нужно оставаться с этой конфигурацией, и что мне действительно нужно блокировать и разблокировать различные запросы и, следовательно, разные потоки.

Это ReadWriteLock, потому что мне нужно разрешить несколько «читателей» или эксклюзивный «писатель».

Похоже, это может быть написано с использованием AbstractQueuedSynchronizer, но я боюсь, что если я напишу сам, сделаю какую-то тонкую ошибку. Я могу найти различные примеры использования AbstractQueuedSynchronizer, но не ReadWriteLock.

Я мог бы взять источник OpenJDK ReentrantReadWriteLock и попытаться удалить реентерабельную часть, но, боюсь, я не получу ее совершенно правильно.

Я смотрел в Guava и Apache Commons, но не нашел ничего подходящего. У Apache Commons есть RWLockManager, который может делать то, что мне нужно, но я не уверен, и это кажется более сложным, чем мне нужно.

Answer 1

Семафор позволяет различным потокам выполнять получение и выпуск разрешений. Эксклюзивная запись эквивалентна наличию всех разрешений, так как поток ожидает, пока все не будут выпущены, и никакие дополнительные разрешения не могут быть получены другими потоками.

final int PERMITS = Integer.MAX_VALUE; 
Semaphore semaphore = new Semaphore(PERMITS); 

// read 
semaphore.acquire(1); 
try { ... } 
finally { 
    semaphore.release(1); 
} 

// write 
semaphore.acquire(PERMITS); 
try { ... } 
finally { 
    semaphore.release(PERMITS); 
} 

Answer 2

Я не уверен, что понимаю вопрос. Неотправляемый ReadWriteLock представляет собой оксюморонную ИМО, дающую слово "reentrant" has specific meaning в народной резьбе. Он должен использоваться из нескольких потоков, иначе он не будет работать. Существует только ReentrantReadWriteLock, который реализует ReadWriteLock в Java 6 JDK, который я вижу. Конечно, множественные чтения могут блокировать ReadWriteLock в то же время, но использовать слово «реентерабель» в этом контексте является сбивающим с толку.

Что вы должны делать, это хороший код для блокировки и разблокировки. Например, всегда используйте блоки try {} finally, чтобы убедиться, что вы получаете каждую разблокировку.

ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); 
Lock readLock = readWriteLock.readLock(); 
... 
readLock.lock(); 
try { 
    ... // do stuff with the data 
} finally { 
    readLock.unlock(); 
} 

Подразумевается, что один поток будет lock() и другой unlock() не так, как вы должны использовать ReadWriteLock. Это очень плохой узор.

выглядит как это может быть написано с использованием AbstractQueuedSynchronizer

Но что будет страдать от тех же проблем, которые у вас возникли в настоящее время. Если вы не используете его надлежащим образом, вы все равно получите доступ к вашим защищенным Collection за пределами блокировки.

Я начал получать IllegalMonitorStateException периодически

Я не был бы быстро винить ReadWriteLock для этого. Я подозреваю, что у вас есть код, который не блокировки коллекции, или что вы произвольно изменяете коллекцию в блокировке чтения.

Answer 3

Не совсем уверен, что вам нужно, особенно. почему он должен быть блокировкой чтения для чтения, но если у вас есть задача, которую нужно обрабатывать многими потоками, и вы не хотите, чтобы это были процессыd/access одновременно, я бы использовал фактически ConcurrentMap (и т. д.).

Вы можете удалить задачу с карты или заменить ее специальным «объектом блокировки», чтобы указать, что она заблокирована. Вы можете вернуть задачу с обновленным состоянием на карту, чтобы разрешить другой поток, или, альтернативно, вы можете передать задачу непосредственно в следующий поток и позволить ему вернуть задачу на карту вместо этого.

Answer 4

Я знаю, что вы уже приняли другой ответ. Но я все еще думаю, что вы собираетесь создать для себя совершенно кошмар. В конце концов, клиент не сможет вернуться и освободить эти разрешения, и вы начнете задаваться вопросом, почему «писатель» никогда не пишет.

Если бы я делал это, я бы сделал это так:

Client issues a request to start a transaction 
The initial request creates a task (Runnable/Callable) and places it in an Executor for execution 
The initial request also registers that task in a Map by transaction id 

Client issues the second request to close the transaction 
The close request finds the task by transaction id in a map 
The close request calls a method on the task to indicate that it should close (probably a signal on a Condition or if data needs to be passed, placing an object in a BlockingQueue) 

Теперь задача транзакции будет иметь такой код:

public void run() { 
    readWriteLock.readLock().lock(); 
    try { 
     //do stuff for initializing this transaction 
     if (condition.await(someDurationAsLong, someTimeUnit)({ 
      //do the rest of the transaction stuff 
     } else { 
      //do some other stuff to back out the transaction 
     } 
    } finally { 
     readWriteLock.readLock.unlock(); 
    } 
} 

Answer 5

Они, кажется, опустили мяч на это одно из устаревших com.sun.corba.se.impl.orbutil.concurrent.Mutex;

Я имею в виду, кто в здравом уме думает, что нам не понадобятся не-реентерабельные замки. Здесь мы находимся, тратя время на то, чтобы обсудить определение реентерабера (может незначительное изменение значения для каждого фрейма кстати). Да, я хочу tryLock в том же потоке, что это плохо? он не зайдет в тупик, потому что иначе не будет. Блокировка без реентера, которая блокируется в одном потоке, может быть очень полезна для предотвращения ошибок в приложениях с графическим интерфейсом, где пользователь нажимает одну и ту же кнопку быстро и многократно. Был там, сделал это, QT был прав ... снова.