Как стать автором
Обновить
29
Карма
0
Рейтинг

Пользователь

typeof(T) vs. TypeOf⟨T⟩

Да, потенциально (хотя не стопроцентный факт, но для меня убедительный) это место может упасть с ArgumentOutOfRangeException из-за возможной гонки при присваивании в две переменные, как упомянул в комментариях retran.

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

Кстати, про syncroot на коллекциях вы не знаете, да?

Знаю, но в некоторых случаях мне хотелось бы абстрагироваться от введения явной переменной, отчего и появился
public static class Lock
{
	public static TResult Invoke<TSyncContext, TResult>(Func<TResult> func)
	{
		lock (func) return func();
	}
}

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

Потенциально возвращенный null вы тоже обрабатываете? Что-то не видно.

Обрабатывается потенциально возвращённый false. :)

typeof(T) vs. TypeOf⟨T⟩

Теперь убедили, потенциально тут может возникнуть ArgumentOutOfRangeException.

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

Моя цель — поделиться идеями, подвергуть их критике и приблизиться истине. Вот с примененим лока на делегате уже нашли изъян, и я признаю, что оказался не прав. :)

Думаю, это заставляет работать умы людей и более глубоко разбираться в вопросах.

typeof(T) vs. TypeOf⟨T⟩

Да, признаю, в этом предположении я оказался не прав. Нужно задавать более надёжный контекст для lock'а. Пример подправлю.

typeof(T) vs. TypeOf⟨T⟩

Изначально я придерживаюсь такого определения:
Словарь, не являясь потокобезопасным классом, способен работать в условиях нескольких потоков, но может давать ненадёжные результаты.

typeof(T) vs. TypeOf⟨T⟩

Пример интересный, но я не вижу аналогии с текущим случаем. Словарь внутри себя не дожидается выполнения потоков и не делает предположений, о значениях переменных. Грубо говоря, это просто массив, который может увеличиваться, сохраняя индексы элементов, с ненадёжным параллельным чтением (один поток может упустить изменения, только что внесённые другим).

typeof(T) vs. TypeOf⟨T⟩

Можно два определения дать потокобезопасности:
1. Гаранития того, что коллекция вообще будет работать в условиях нескольких потоков
2. Гарантия того, что при записи/удалении/замене элемента одним потоком, второй изменения сразу же увидит

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

typeof(T) vs. TypeOf⟨T⟩

Запись элементов идёт только под lock'ом. То есть я допускаю лишь ситуацию с ненадёжным параллельным чтением, которая обрабатывается под тем же lock'ом.

typeof(T) vs. TypeOf⟨T⟩

Не вижу причин для падения даже при параллельном Clear.

typeof(T) vs. TypeOf⟨T⟩

Возможно, для других сценариев это критично, что накладывает ограничения на применение, но для конкретного допустимо.

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

Её, как будто, гарантируют CLR и компилятор при инициализации статической переменной
    [CompilerGenerated]
    private sealed class <>c
    {
        public static readonly <>c <>9 = new <>c();

(декомпиляция)

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

Чтобы воспроизвести такое нужны примеры намного похитрее, чем наш. :)

typeof(T) vs. TypeOf⟨T⟩

По сути TryGetValue гарантирует, что не будет исключений из какого бы мы потока не работали со словарём. Может только false вернуться при несинхронном добавлении элемента из другого потока (поскольку словарь непотокобезопасный). Этот второй случай обрабатывается повторным чтением в lock.

Мне так видится реализация.

typeof(T) vs. TypeOf⟨T⟩

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

Информация

В рейтинге
5,833-й
Зарегистрирован
Активность