Comments 11
Может быть стоило бы и заголовок статьи перевести?
А еще у меня вопрос.
На сколько я понял, у вас один кэш на все вызовы методов. Соответственно, если вызывается метод из двух потоков с разными аргументами, то один из них будет стоять на lock'e, ожидая другого с другими аргументами, хотя смысла в этом ожидании нет. Разве не так?
На сколько я понял, у вас один кэш на все вызовы методов. Соответственно, если вызывается метод из двух потоков с разными аргументами, то один из них будет стоять на lock'e, ожидая другого с другими аргументами, хотя смысла в этом ожидании нет. Разве не так?
… поэтому мы должны проверить существование ключа дважды: вне заблокированного кода и внутри его...
Это называется double-checked lock.
И да, в очень редких случаях даже он может профейлить, поэтому при выходе из лока надо дёрнуть Thread.MemoryBarrier();
Вообще говоря, хитростей много. Статья ориентирована на любой уровень подготовки, потому объясняется все :)
А вот тут мне уже стало очень интересно.
Можно подробнее о double-checked lock & Thread.MemoryBarrier()?
Можно подробнее о double-checked lock & Thread.MemoryBarrier()?
msdn.microsoft.com/en-us/library/system.threading.thread.memorybarrier.aspx
>MemoryBarrier is required only on multiprocessor systems with weak memory ordering (for example, a system employing multiple Intel Itanium processors).
For most purposes, the C# lock statement, the Visual Basic SyncLock statement, or the Monitor class provide easier ways to synchronize data.
www.albahari.com/threading/part4.aspx
>MemoryBarrier is required only on multiprocessor systems with weak memory ordering (for example, a system employing multiple Intel Itanium processors).
For most purposes, the C# lock statement, the Visual Basic SyncLock statement, or the Monitor class provide easier ways to synchronize data.
www.albahari.com/threading/part4.aspx
Sign up to leave a comment.
Postsharp. Решаем задачу кэширования