Действительно ли имеет смысл синхронизировать map.get (key), когда значение AtomicLong, когда мы хотим использовать map.get (key) .wait ()? - PullRequest
Новая
       20

Действительно ли имеет смысл синхронизировать map.get (key), когда значение AtomicLong, когда мы хотим использовать map.get (key) .wait ()?

0 голосов
/ 28 марта 2019

То, что я пытаюсь сделать, это реализовать специфическую для ключа блокировку чтения-записи . Несколько запросов на чтение могут выполняться одновременно, если для этого ключа нет запроса на запись. Запросы на разные ключи могут выполняться одновременно. Я использовал ConcurrentHashMap, чтобы сохранить ключ и вести учет запущенных операций записи для каждого ключа.

Мой код выглядит так: 

ConcurrentHashMap<String, AtomicInteger> count;
...
...
public void getLock(){
    synchronized (count.get(key)) {
        while (count.get(key).get() != 0) { // this means there are GET                                     
                                          requests running
            try {
                count.get(key).wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

Идея состоит в том, что, когда новый поток хочет прочитать, он должен сначала проверить, есть ли какая-либо запись по этому ключу (если счет не равен 0), и если нет, он может идти вперед, если да, он должен Подождите. Поэтому я полагаю, что я должен использовать count.get(key).wait();. Тем не менее, Java вынуждает меня synchronized (count.get(key)) использовать метод wait().

Интересно, имеет ли смысл использовать здесь синхронизацию, поскольку я уже использую AtomicInteger?

p.s. У меня есть notify() позже в методе разблокировки.

1 Ответ

0 голосов
/ 28 марта 2019

Я только что понял, почему мне все еще нужен синхронизированный блок для AtomicInteger.Все комментарии, а также эта ссылка очень полезны.

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

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

...