#c# #.net #clr
#c# #.net #clr
Вопрос:
Я понимаю цель SynchronizationContext и подходящее время для его использования. Но одна вещь, в которой я все еще запутался, — это SynchronizationContext.Send .
Я не понимаю, почему существует SynchronizationContext .Отправляйте, когда кажется, что Post уже достаточно. Я понимаю, что отправка предназначена для синхронного вызова. Но при каких обстоятельствах Send() полезен?
И еще один связанный с этим вопрос: когда я разрабатываю свой настроенный SynchronizationContext, когда я должен переопределить Send() ? Должен ли я?
Комментарии:
1.
Sendотправляет асинхронное сообщение в контекст и ожидает его завершения , как указано вPostприложении, которого нет. Поскольку вы, вероятно, не контролируете то, что может вызывать контекст, было бы разумно реализовать его. Наконец, большинству разработчиков никогда не нужно создавать пользовательский контекст синхронизации, это не самая тривиальная вещь для реализации, мои чувства паука подсказывают мне, что это проблема X / Y. Каков здесь вариант использования?2. Спасибо @MichaelRandall, вариант использования заключается в том, что мне нужно убедиться, что каждое ожидаемое продолжение отправляется обратно в мой специальный пул потоков, который имеет некоторые специальные инструменты, необходимые для моего конкретного вида сервиса. Что касается Send(), я понимаю часть «ожидание завершения», я просто не знаю, какой конкретный сценарий оправдал бы существование этого метода. Другое дело, если я могу «не переопределять» его и оставить его для реализации по умолчанию (базовой) (которая просто вызывает обратный вызов в текущем потоке)
3. Еще одна вещь, которую нужно добавить, это то, что я пытался реализовать Send, но он никогда не вызывался в моих тестовых примерах. Я не знаю, как вызвать вызов Send() с помощью тестового кода. Кроме того, я вижу, что люди реализуют Send() с помощью throw NotSupportedException() , теперь я не знаю, вызовет ли это проблемы в будущем или это ожидаемое поведение .net framework, т.Е. Если платформа видит, что Send() выдает NotSupportedException, это будет запасной вариант для вызова Post() (звучит маловероятнохотя, поскольку это было бы большим ударом по производительности)
4. «Конкретный» вариант использования
Send— это когда метод предоставляет нужный вам результат. Многие реализацииSend, которые я видел, будут выполнять делегат напрямую, а не ставить в очередь и ждать, если он определит, что метод будет / может быть выполнен текущим потоком. Большинство реализаций, которые вводят,Sendвероятно, делают это, потому что задачи не используют его и им все равно ни о чем другом (SynchronizationContext предшествует Task с большим отрывом).5. Я думаю, что дизайн SynchronizationContext на самом деле был просто тонкой абстракцией над отправкой / отправкой оконных сообщений.