безопасность потоков при взаимодействии с кешем

Question

У меня есть вопрос, который поможет мне понять безопасность потоков и параллелизм в моем приложении .net c #.

Например, чтение и запись из кэша asp.net.

Я занимаюсь разработкой крупномасштабного .net-приложения с взаимодействием с кешем.

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

При взаимодействии с кешем я должен использовать блокировки, чтобы гарантировать, что кеш не будет манипулироваться несколькими потоками во время чтения и записи в него. Так я должен использовать замки? И как это сочетается с параллелизмом?

Answer 1

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

Сам объект ASP.NET-кэша является поточно-ориентированным. Вы можете получить к нему доступ из нескольких потоков без ущерба для самой коллекции. Однако вы сами несете ответственность за обеспечение безопасности потоков для объектов, которые вы помещаете в кеш.

Самый простой подход, вероятно, состоит в том, чтобы сделать все объекты, которые должны быть помещены в кэш, неизменяемыми (например, класс .NET string). После создания объект никогда не будет обновлен и будет прочитан только из. Операции только для чтения всегда потокобезопасны. Если вам нужно обновить данные, вы создаете новый объект на основе старого и заменяете объект в кеше. Таким образом, вам не придется заниматься безопасностью потоков самостоятельно, поскольку вы можете полагаться на объект кэша для этого.

Если вам необходимо обновить объекты в кэше, вы должны убедиться, что все операции обновления этих объектов являются потокобезопасными.

Answer 2

В сущности, оптимистические схемы блокировки основаны на идее, что при нормальной работе запись в одни и те же данные не будет параллельной.Таким образом, у них есть своего рода механизм управления версиями, так что потенциальное столкновение может быть обнаружено, и они выдают ошибку.В приложениях Crud, которые обычно «кто-то другой изменил эти данные, пожалуйста, попробуйте еще раз», и, надеюсь, вернут текущие данные, чтобы это можно было сделать.

Пессимистичные схемы блокировки предполагают, что при нормальной работе основная часть записей будет параллельной, поэтому блокировка взята, и одновременное обновление не может быть выполнено, пока текущая запись не будет завершена.В приложении CRUD, которое выглядело бы как «Пользователь Фред заблокировал счет клиента, повторите попытку позже.

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