Сообщение Re[2]: Вопрос про Lazy<T> от 01.12.2017 15:52
Изменено 01.12.2017 15:52 SergASh
Re[2]: Вопрос про Lazy<T>
Здравствуйте, Sinix, Вы писали:
S>Lazy отвечает только за создание ресурса. Так что или lock (общий для всех действий над ресурсом, чтобы не ресетнуть посередине обработчика), или обдумать исходную проблему и написать код так, чтобы в комбо разделяемый доступ + reset не было необходимости.
Увы, не могу удовлетвориться таким ответом. Хотелось бы чего-то в том же духе, как ConcurrentDictionary выполняет функцию атомарно во вставкой и без блокировки. Видить придется свой Lazy выдумывать.
S>Lazy отвечает только за создание ресурса. Так что или lock (общий для всех действий над ресурсом, чтобы не ресетнуть посередине обработчика), или обдумать исходную проблему и написать код так, чтобы в комбо разделяемый доступ + reset не было необходимости.
Увы, не могу удовлетвориться таким ответом. Хотелось бы чего-то в том же духе, как ConcurrentDictionary выполняет функцию атомарно во вставкой и без блокировки. Видить придется свой Lazy выдумывать.
Re[2]: Вопрос про Lazy<T>
Здравствуйте, Sinix, Вы писали:
S>Lazy отвечает только за создание ресурса. Так что или lock (общий для всех действий над ресурсом, чтобы не ресетнуть посередине обработчика), или обдумать исходную проблему и написать код так, чтобы в комбо разделяемый доступ + reset не было необходимости.
Увы, не могу удовлетвориться таким ответом. Хотелось бы чего-то в том же духе, как ConcurrentDictionary выполняет функцию атомарно во вставкой и без блокировки. Видать, придется свой Lazy выдумывать.
S>Lazy отвечает только за создание ресурса. Так что или lock (общий для всех действий над ресурсом, чтобы не ресетнуть посередине обработчика), или обдумать исходную проблему и написать код так, чтобы в комбо разделяемый доступ + reset не было необходимости.
Увы, не могу удовлетвориться таким ответом. Хотелось бы чего-то в том же духе, как ConcurrentDictionary выполняет функцию атомарно во вставкой и без блокировки. Видать, придется свой Lazy выдумывать.