Java ReentrantReadWriteLocks - как безопасно получить блокировку записи?

То, что Вы ищете, является обновлением блокировки и не возможно (по крайней мере, не атомарно) использование стандартного java.concurrent ReentrantReadWriteLock. Ваш лучший выстрел, разблокируют/блокируют, и затем проверяют, что никто не сделал промежуток модификаций.

, Что Вы пытаетесь сделать, принуждение всех блокировок чтения из пути не является очень хорошей идеей. Читайте блокировки там по причине, которую Вы не должны писать.:)

РЕДАКТИРОВАНИЕ:
, Как Выполнил Biron, на которого указывают, если Вашей проблемой является исчерпание ресурсов (блокировки чтения устанавливаются и выпускаются все время, никогда не опускаясь до нуля) Вы могли попытаться использовать справедливую организацию очередей. Но Ваш вопрос не казался, что это было Вашей проблемой?

РЕДАКТИРОВАНИЕ 2:
я теперь вижу Вашу проблему, Вы на самом деле получили несколько блокировок чтения на стеке, и требуется преобразовать их в блокировку записи (обновление). Это на самом деле невозможно с реализацией JDK, поскольку она не отслеживает владельцев блокировки чтения. Могли быть другие, держащие блокировки чтения, которые Вы не будете видеть, и это понятия не имеет, сколько из блокировок чтения принадлежит Вашему потоку, не говоря уже о Вашем текущем стеке вызовов (т.е. Ваш цикл уничтожает весь блокировки чтения, не только Ваше собственное, таким образом, Ваша блокировка записи не будет ожидать никаких параллельных читателей для окончания, и Вы закончите с путаницей на Ваших руках)

, у меня на самом деле была подобная проблема, и я закончил тем, что писал свою собственную блокировку, отслеживающую того, кто получен что блокировки чтения и обновляющий их до блокировок записи. Хотя это было также видом Копии на записи блокировки чтения-записи (разрешающий одному писателю вдоль читателей), таким образом, это немного отличалось все еще.

Я предполагаю эти ReentrantLock, мотивирован рекурсивным обходом дерева:

public void doSomething(Node node) {
  // Acquire reentrant lock
  ... // Do something, possibly acquire write lock
  for (Node child : node.childs) {
    doSomething(child);
  }
  // Release reentrant lock
}

разве Вы не можете осуществить рефакторинг свой код для перемещения обработки блокировки за пределами рекурсии?

public void doSomething(Node node) {
  // Acquire NON-reentrant read lock
  recurseDoSomething(node);
  // Release NON-reentrant read lock
}

private void recurseDoSomething(Node node) {
  ... // Do something, possibly acquire write lock
  for (Node child : node.childs) {
    recurseDoSomething(child);
  }
}

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

То, что вы пытаетесь сделать, таким образом просто невозможно.

У вас не может быть блокировки чтения / записи, которую можно без проблем модернизировать с чтения на запись. Пример:

void test() {
    lock.readLock().lock();
    ...
    if ( ... ) {
        lock.writeLock.lock();
        ...
        lock.writeLock.unlock();
    }
    lock.readLock().unlock();
}

Теперь предположим, что в эту функцию войдут два потока. (И вы предполагаете, что параллелизм, не так ли? В противном случае вам не нужны блокировки в первую очередь ....)

Предположим, что оба потока будут запускаться одновременно и работать одинаково быстро. . Это означало бы, что оба получат блокировку чтения, что совершенно законно. Однако тогда оба в конечном итоге попытаются получить блокировку записи, которую НИ ОДИН из них никогда не получит: соответствующие другие потоки удерживают блокировку чтения!

Блокировки, которые позволяют модернизировать блокировки чтения до блокировок записи, по определению подвержены взаимоблокировкам. Извините, но вам нужно изменить свой подход.

в OP: просто разблокируйте столько раз, сколько вы входили в замок, просто как это:

boolean needWrite = false;
readLock.lock()
try{
  needWrite = checkState();
}finally{
  readLock().unlock()
}

//the state is free to change right here, but not likely
//see who has handled it under the write lock, if need be
if (needWrite){
  writeLock().lock();
  try{
    if (checkState()){//check again under the exclusive write lock
   //modify state
    }
  }finally{
    writeLock.unlock()
  }
}

в блокировке записи, поскольку любая уважающая себя параллельная программа проверяет необходимое состояние.

HoldCount не следует использовать, кроме отладки / отслеживания / быстрого обнаружения сбоев.