Было бы интересно взглянуть на подобное решение. Сейчас пользуемся ObservablePropertyAttribute, но он покрывает лишь часть потребностей. Пока даже филды не завозят. Про такое уже остается мечтать)
Засада и правда коварная) Для нового лока такой случай смогли находить, а для мониторов поддержку не завезли. Что касается второго, то честно говоря не обладаю большой экспертностью в области класса Monitor, поэтому конкретику внести не смогу. Надеюсь, найдутся коллеги, которые более осведомлены в данном вопросе.
Спасибо за развернутый ответ по асинхронщине в Lock. Мы сейчас используем SemaphoreSlim для подобных случаев) Вот как только переехали в одном из проектов на асинхронность, то сразу же заменили Lock на SemaphoreSlim. Пока полет нормальный.
После написания для вьюшек n-го количества моделей с доп. логикой в сеттере, использование ключевого слова field для меня является глотком свежего воздуха. Сейчас поля для свойств захламляют класс, делая его менее читабельным (имхо). Если не ошибаюсь, еще в C# 10 хотели такую фичу добавить. Видимо не в приоритете(
Структура Scope, которую мы получаем, не реализует асинхронную версию метода Dipose(), поэтому мы получим ошибку от компилятора. Но я нашел веселее момент, в рантайме. Можно в теории что-либо асинхронное указать между методами Enter() и Exit(). Компилятор никак на это не отреагирует, но при Runtime мы получим дичь в работе Lock)) Замечу, что при использовании скоупа компилятор отлично реагирует на такие попытки (даже при использовании using без блочных скобок).
В теории свойство должно обеспечить надежность в этом плане. Если мы обратимся из другого потока, то у нас и правда может выпасть исключение "SynchronizationLockException", что неохорошо. Я уверен, что можно круче обработать точку выхода из лока, чем показано в статье. С другой стороны можно использовать Scope структуру, Dispose() которой будет применен при выходе из области видимости.
Как ответил @DoctorKrolic, по-сути это одно и то же. Думаю, с помощью нового класса Lock будет проще переехать с Monitor на локи (нейминг методов больно схож).
Было бы интересно взглянуть на подобное решение. Сейчас пользуемся
ObservablePropertyAttribute, но он покрывает лишь часть потребностей.Пока даже филды не завозят. Про такое уже остается мечтать)
Спасибо за подробный ответ. Суть понятна)
p.s. Рефлексия в C++ звучит интересно. Надо будет глянуть :)
Да, тут больше про вероятность освобождения внутри тела
try. Так сказать: "на всякий случай".Слышал про такое "явление" от разработчиков C++. Что-то на тяжелом)
Засада и правда коварная) Для нового лока такой случай смогли находить, а для мониторов поддержку не завезли.
Что касается второго, то честно говоря не обладаю большой экспертностью в области класса
Monitor, поэтому конкретику внести не смогу. Надеюсь, найдутся коллеги, которые более осведомлены в данном вопросе.Хочется сказать: "В первый раз?")
База. Думаю, что найдутся ошибки при такой инициализации объекта. Будто 2 разных человека делали :) (думаю, так и есть).
Спасибо за развернутый ответ по асинхронщине в
Lock.Мы сейчас используем
SemaphoreSlimдля подобных случаев) Вот как только переехали в одном из проектов на асинхронность, то сразу же заменилиLockнаSemaphoreSlim. Пока полет нормальный.После написания для вьюшек n-го количества моделей с доп. логикой в сеттере, использование ключевого слова
fieldдля меня является глотком свежего воздуха. Сейчас поля для свойств захламляют класс, делая его менее читабельным (имхо).Если не ошибаюсь, еще в C# 10 хотели такую фичу добавить. Видимо не в приоритете(
Структура Scope, которую мы получаем, не реализует асинхронную версию метода
Dipose(), поэтому мы получим ошибку от компилятора. Но я нашел веселее момент, в рантайме. Можно в теории что-либо асинхронное указать между методами Enter() и Exit(). Компилятор никак на это не отреагирует, но при Runtime мы получим дичь в работе Lock))Замечу, что при использовании скоупа компилятор отлично реагирует на такие попытки (даже при использовании using без блочных скобок).
В теории свойство должно обеспечить надежность в этом плане. Если мы обратимся из другого потока, то у нас и правда может выпасть исключение "SynchronizationLockException", что неохорошо. Я уверен, что можно круче обработать точку выхода из лока, чем показано в статье.
С другой стороны можно использовать Scope структуру,
Dispose()которой будет применен при выходе из области видимости.Развития эта фича пока не получила. Я больше жду, когда field добавят для свойств, т.к. выглядит очень удобно и потенциально уменьшит количество кода.
Да, хотелось бы иметь возможность применять асинхронщину внутри. Что тут скажешь... Ждем)
Как ответил @DoctorKrolic, по-сути это одно и то же. Думаю, с помощью нового класса Lock будет проще переехать с Monitor на локи (нейминг методов больно схож).
Не знал, что есть хакатоны не только в сфере it... Мой мир не станет прежним...
Крутая и очень интересная статья!