Создать потокобезопасный кеш одноразовых объектов

Question

Мне нужно создать потокобезопасный кеш одноразовых объектов. Как я это вижу:

1. У меня есть класс данных, что я хочу, чтобы кэшировать, бывший MyData
2. Я создаю некоторые коллекции (ConcurrentDictionary, например) для MyData
3. У меня есть метод, который создает новый экземпляр MyData, используя некоторый ключ.
4. Когда мне нужно получить MyData для некоторого ключа, я проверяю, существует ли он в моем хранилище, а затем используйте его из коллекции, иначе он создает новый экземпляр и помещает его в коллекцию.
5. У меня есть событие, когда я должен аннулировать кеш. На этом событии я очищаю хранилище.

Недостатки в том, что MyData является одноразовым. Я не знаю, когда следует вызвать метод Dispose. Я не могу вызвать метод Dispose при очистке коллекции от события clear-cache, потому что какой-то поток может мгновенно использовать эти экземпляры MyData.

Какой шаблон выбрать?

Answer 1

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

Наиболее очевидно, что вы можете сделать здесь, это использовать ReaderWriteLockSlim и обертку вокруг обычного Dictionary<TKey, TValue>.

Когда кто-то хочет использовать элемент из кеша, он получает доступ для чтения. Когда кто-то хочет изменить кеш (вообще добавить элемент или вообще недействить кеш), он получает доступ на запись (следовательно, автор не может аннулировать кеш, пока последний читатель не освободит блокировку).

Другой вариант - рассмотреть подход, когда вы просто ловите ObjectDisposedException. Но этот подход предполагает, что работа с currect может быть прервана извне.

Answer 2

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

Answer 3

Если объекты являются логически неизменными, несколько дорогими для создания и, как известно, не потребляют неисправимых ресурсов и лишь небольшое количество взаимозаменяемых; и если отслеживание всех ссылок на них будет непрактичным, вы можете использовать кеш коротких слабых ссылок. Такая ситуация была бы одним из немногих раз, когда я мог бы считать разумным «полагаться» на завершение, поскольку только один объект, соответствующий данному ключу, когда-либо существовал бы за пределами «freachable» очереди (список объектов, нуждающихся в очистке) в любой момент времени , Одним из преимуществ этого подхода является то, что при условии, что вы избежите воскрешения объектов, которые стали пригодными для завершения, вашему коду не нужно слишком беспокоиться о проблемах с потоками в большинстве случаев. Вам придется периодически чистить записи, связанные с ними слабые ссылки, и следить за тем, что запись в кэш может быть обновлена ​​новым объектом после того, как он будет признан мертвым, но GC должен обеспечить, чтобы объекты не очищайтесь, пока кто-то их использует.