Было бы интересно взглянуть на подобное решение. Сейчас пользуемся 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... Мой мир не станет прежним...
Крутая и очень интересная статья!