Блог

Мне интересно, есть ли лучшая схема блокировки для кэша, чем простая блокировка:

 Mutex lock;
get(key) {
  LockGuard(lock);

  if (cache.has(key)) {
    return cache[key];
  } else {
    data = remoteclient.getslow();
    cache[key] = data;
    return data;
  }
}
  

Предполагая, что у вас много одинаковых запросов, вы каждый раз сериализуете доступ к get() . Можно ли сделать что-то более разумное с блокировками ReadWriter?

т.е. что, если вы сделаете что-то вроде:

 ReadersWritersLock lock;
get(key) {
  {
    ReadLockGuard(lock);
    if (cache.has(key)) {
      return cache[key];
    } 
  }
  WriteLockGuard(lock);
  data = remoteclient.getslow();
  cache[key] = data;
  return data;
 }
}
  

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

Любые другие идеи по оптимизации такого рода кода?

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

 remoteclient.getslow();
  

вызывается, когда кэш заблокирован. Если remoteclient.getslow() на самом деле, вероятно, потребуется много времени для возврата (как указывает название), то любые другие потоки, пытающиеся получить доступ к кэшу, в конечном итоге будут заблокированы на долгое время (т. Е. До тех пор, пока getslow() не вернется, и поток, который его вызывал, снимет блокировку)… даже если их интересуют только несвязанные данные, которые уже присутствуют в кэше!

Чтобы избежать этого, я бы вызвал remoteclient.getslow() вместо этого вне области действия LockGuard (т. Е. Пока кэш разблокирован). Затем, после того, как remoteclient.getslow() вернет результат, я бы повторно заблокировал кеш и обновил кеш полученным значением. Таким образом, кэш никогда не блокируется на длительные периоды.

(Конечно, выполнение этого таким образом открывает возможность для нескольких потоков, вызывающих remoteclient.getslow() для одного и того же элемента данных, если все они решат, что им нужны одни и те же данные примерно в одно и то же время… но это может быть приемлемым побочным эффектом. Или, если нет, вы могли бы разработать механизм, указывающий, что определенное значение кэша находится в процессе извлечения, и блокировать другие потоки до завершения извлечения … если это стоит дополнительной сложности для вас. Для этого, вероятно, потребуются переменные условия и тому Подобное)

Ваш псевдокод имеет правильную идею, но у него есть условие гонки.

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

Если ваша реализация блокировки чтения / записи поддерживает обновляемые блокировки, вам следует использовать это. В противном случае, после захвата блокировки для записи, вам необходимо дважды проверить кэш на случай, если он был заполнен между выпуском «reader» и получением «writer».

Возможно, что два потока войдут в «записывающую» часть get(), но, вероятно, очень маловероятно. Если вас беспокоит штраф за дополнительный вызов getslow(), вы можете снова проверить внутри блокировки записи.

 ReadersWritersLock lock;
get(key) {
  {
    ReadLockGuard(lock);
    if (cache.has(key)) {
      return cache[key];
    } 
  }
  WriteLockGuard(lock);
  if (cache.has(key) == false) {
    data = remoteclient.getslow();
    cache[key] = data;
    return data;
  }
 }