Почему мой BeginInvoke работает синхронно

Question

Я создал приложение WCF, и в нескольких местах я использую BeginInvoke для асинхронного запуска методов. В некоторых местах он асинхронен, а в других - синхронно. Поскольку система довольно сложная, я надеялся просто бросить этот вопрос высокого уровня там, надеясь, что кто-то знает причину, по которой BeginInvoke будет вынужден работать синхронно.

Возможные причины я Рассмотренные и считают, не являются причиной:

• Я выбежал из Threadpool темы - Я думаю, что на пике я использую менее 20 потоков.
• Я использую блокировки через эти потоки останавливая их одновременно расстрелы - синхронизация не используется, так как каждый вызов к методу на отдельном WCF ServiceHost
• асинхронного метод родительского (который определенно работает асинхронно) вызывает много детей BeginInvokes и вас не может встраивать асинхронные вызовы - я не думаю, что это ограничение
• Родительский асинхронный метод сам по себе является частью WCF ServiceHost, который является InstanceContextMode.PerSession, и есть некоторые ограничения на его вложение асинхронных вызовов. Опять же, я не знаю Так думает, но FYI
• Каждый вызываемый ребенок является (отличным от родителя) WCF ServiceHost, метод которого я звоню, является инстансом e того же ServiceType и запускается как InstanceContextMode.Single и ConcurrencyMode.Single. - Значит ли это каким-то образом удара при вызове подпрограммы из работы тех асинхронно (я не понимаю, почему это было, но на всякий случай)

Любые идеи/решения очень ценятся

Answer 1

Я хотел бы ссылаться на эту цитату относительно Delegate.BeginInvoke от Джо Даффи в своей книге Параллельное программирование на Windows:

Все типы делегата, по соглашению предлагают метод BeginInvoke и EndInvoke наряду с обычным синхронным методом Invoke. Хотя это хорошая функция модели программирования, вы должны держаться подальше от них, где это возможно. В реализации используется удаленная инфраструктура, которая накладывает значительные ажурные накладные расходы на асинхронный вызов. Работа в очереди в пуле потоков напрямую часто является лучшим подходом, хотя это означает, что вам нужно координировать логику рандеву самостоятельно.

Я уже делал свои собственные тесты, и накладные расходы могут составлять много секунд при частом использовании. Возможно, это не ответ на ваш вопрос, потому что было бы почти невозможно, я думаю, не видя и не отлаживая код. Это скорее предположение, что вы должны еще раз взглянуть на ваш подход. Возможно, работа в очереди на ThreadPool напрямую или с помощью TPL (Ожидание задачи/async &).

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