Поиск альтернативы ReentrantLock, подобной приоритетной очереди, для кражи блокировок из других потоков.
У меня есть набор завернутый ReentrantLocks которые имеют уникальные целочисленные идентификаторы, где я требую, чтобы потоки получали блокировки с более низким идентификатором, прежде чем они получат блокировки с более высоким идентификатором, чтобы предотвратить тупик. Три из блокировок (lock0, lock1 и lock2) имеют больший приоритет, чем блокировки с более высокими идентификаторами, в то время как все другие блокировки имеют одинаковый приоритет - это означает, что если поток получает одну из этих трех высокоприоритетных блокировок, то они необходимо прервать другие потоки, которые удерживают необходимые блокировки с низким приоритетом. Например, Thread1 удерживает lock4 и lock5, а Thread0 удерживает lock0 и нуждается в lock4 и lock5, поэтому Thread0 прерывает Thread1 (который получил свои блокировки, используя lockInterruptibly и который иногда запрашивает его isInterrupted метод) и берет свои замки. Thread1 ожидает, пока не будет получен сигнал от Thread0 (то есть он не попытается повторно получить блокировки, пока Thread0 не закончит с ними).
Это не идеально по нескольким причинам. В идеале я бы хотел, чтобы Thread0 немедленно сигнализировал о том, что ему нужна блокировка, чтобы другие потоки не прыгали вперед и не получали блокировку, пока Thread1 заботится о прерывании Thread0 (т. Е. Thread0 попадает в очередь ожидающих потоков, так что если Thread2 пытается чтобы получить блокировку, когда Thread0 прерывает Thread1, тогда Thread0 все еще получит блокировку до Thread2) - например, я хотел бы tryLock вариант, который добавляет поток в очередь блокировки, если другой поток удерживает блокировку. Кроме того, в настоящее время, если есть потоки, поставленные в очередь на lock4 или lock5, то Thread0 должен ждать, пока они получат блокировку, а затем прервать их - было бы лучше, если бы Thread0 мог очистить очередь ожидания на блокировках (при условии, что ни один из ожидающих темы удерживаются приоритетными блокировками). Наконец, нет необходимости в том, чтобы Thread1 отказывался от всех своих блокировок: в случае, когда Thread0 хочет получить lock0 и lock5, в то время как Thread1 хочет получить lock4 и lock5, тогда Thread1 не нужно снимать свою блокировку на lock4, но lockInterruptibly заставит поток отказаться от всех своих блокировок при прерывании (при условии, что поток был прерван во время ожидания получения блокировки).
Прежде чем я заново изобрел колесо, мне было интересно, существует ли класс блокировки, который уже реализовал некоторые / все эти требования, своего рода PriorityReentrantLock или что угодно. Я посмотрел на AbstractQueuedSynchronizer и я не думаю, что с моей стороны потребовалось бы слишком много работы, чтобы изменить его для удовлетворения моих потребностей (тем более, что мне нужны только два приоритета), но чем меньше нового кода мне нужно для тестирования, тем лучше.