Собственно, вопрос.
Используются ли данные штуки в современном C#?
Как я понимаю, они нужны для того, что бы заставить работать с объектом в однопоточной манере, незаморачиваясь с lock'ми
.
Я прочитал некоторые статьи, где писалось, что этих вещей лучше избегать, так как класс становится ограниченным и какой-нибудь стандартный lock
профитнее. Так ли это или в каких сценариях это может пригодится?
На сколько я знаю, то только UI поток "из коробки" имеет свой SynchronuzationContext
?
В современном C# они широко используются "за кулисами".
Например, в WinForms можно использовать SynchronizationContext.Send
и SynchronizationContext.Post
, а можно их эквиваленты Control.Invoke
и Control.BeginInvoke
.
В TAP часто используется TaskScheduler.FromCurrentSynchronizationContext()
при необходимости работать с GUI. То есть захватывается контекст и сообщения отправляются в него. Это проще и удобнее.
ContextBoundObject используется в технологии NET.Remoting. Он есть "в коробке"
Оборудование для ресторана: новинки профессиональной кухонной техники
Частный дом престарелых в Киеве: комфорт, забота и профессиональный уход
Извиняюсь за туфтологию, но в общем то проблема примерно так и выглядит
Здравствуйте хотел спросить как организовать HTTP WepApi доступ к приложению на WPFНеобходимо реализовать контроль состояния объекта (GET запросы...
Реализовывал счетчик задач с очередью, но возникает timeout на последней пачке запросов, клиент ожидает и соединение разрываетсяСкорее всего...