Именно в данном случае race condition.

-----

В данном случае у меня управление вызовом - внешнее. Т.е. Я точно знаю, что назначение (+=) будет сделано ДО того как потребуется вызов.

То, что фактическая имплементация допускает возникновение расе кондитион - это уже отдельно.

Ну да это не критично - в живой системе сканеры создаются в мультитоне, там же, при создании, задается обработчик. Запуск происходит позднее.

Так что советую почитать доку по нему.

-----

Читал. Не помогает.

Недавно рассматривали решение с шарингом стрима между объектами потоков. Перерыл все до исходников - решения не нашел. Пришлось реализовывать по старинке.

Читай

-----

Видимо ты меня хотел вот сюда послать: https://msdn.microsoft.com/en-us/library/system.componentm...

Увы, у меня это не используется.

У меня либо есть данные и тогда вызывается метод обработки, либо данных нет и тогда все спит.

Руннер, как видно из примера, находится в том же воркере и поставляет наружу только корректные

данные.

Завершение работы - не предусмотрено. Совсем. Все возможные ошибки данных - обрабатываются

в вызываемом методе. Ошибки коммуникации с ком-портом - в руннере.

Хотя, скорее всего, следующим шагом будет проверка на жив ли поток и перезапуск если сдох...