Чтение / запись в и из общего кэша на основе Enterprise Library - PullRequest
2 голосов
/ 16 сентября 2011

Я использую блок приложения Enterprise Lib 5.0 для кэширования и пытаюсь найти лучший способ обработки операций чтения / записи в многопоточном сценарии.Рекомендуется ли использовать блокировку при записи и не блокировать чтение при чтении?

Update(string key, object value)
{
     lock(syncLock)
     { 
        cacheManager.Add(key,value);
     }
}
object Read(string key)
{
     object o = cacheManager.GetData(key);
     return o;
 }
  //OR is the following Read recommended using a lock
object Read(string key)
{   
     lock(syncLock)
     {
       object o = cacheManager.GetData(key);
       return o;
     }
}

Меня беспокоит то, что если один поток собирается обновить элемент для определенного ключа одновременно с другим потокомсобирается прочитать элемент для того же ключа. Может ли это быть причиной гонок?

Имеет ли смысл иметь словарь "ключей" для "ReaderWriterLockSlim", чтобы вы по сути взяли блокировку только дляключ Specc, а не «общая» блокировка в многопоточном сценарии, таком как веб-приложение:

По сути, что-то вроде этого:

Dictionary<string,ReaderWriterLockSlim> dict = new Dictionary<string,ReaderWriterLockSlim> ();

void Update(string key, object value)
{
     dict[key].EnterWriteLock();
     cacheManager.Add(key,value);
     dict[key].ExitWriteLock();         
}

object Read(string key)
{
     dict[key].EnterReadLock();    
     object o = cacheManager.GetData(key);
     dict[key].ExitReadLock();    
     return o;
 }

1 Ответ

3 голосов
/ 16 сентября 2011

Вам не нужно делать свою собственную блокировку с Блок приложения кэширования , потому что "вы уверены, что блок работает в поточно-ориентированном режиме".

Если вы беретеВзглянув на исходный код Cache, вы увидите, что все методы Add, Remove и GetData получают блокировки в кэше в памяти перед выполнением каких-либо операций.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...