STAThread и захват процесса вывода в c #

Question

Это странная проблема, с которой я столкнулся. У меня есть оконное приложение, написанное на c # для тестирования. Он имеет родительскую форму MDI, которая содержит несколько дочерних форм. Одна из форм запускает тестовые сценарии, создавая процессы и записывая сценарии, выводимые в текстовое поле. Другая форма - открытый последовательный порт и мониторинг состояния устройства, над которым я работаю (например, оболочка). Если я запустил их оба вместе, вывод скрипта, похоже, появится только в текстовом поле после завершения теста. Однако, если я не открою форму последовательного порта, вывод скрипта будет записан в режиме реального времени.

Кто-нибудь знает, в чем причина проблемы? Я заметил, что обработчик onTataReceived evenT для формы последовательного порта имеет заголовок [STAThread]. Это приведет к тому, что поток последовательного порта будет иметь более высокий приоритет, чем другие процессы?

Заранее спасибо.

Answer 1

STATHREAD требуется для потока пользовательского интерфейса. Из MSDN:

Указывает, что модель потоков COM для приложения является однопоточным (STA).

Кроме того, приложение Windows Form будет иметь только один поток пользовательского интерфейса. Похоже, что для того, чтобы иметь отзывчивый пользовательский интерфейс, вам нужно использовать фоновый рабочий поток для управления запуском вашего скрипта и передавать изменения обратно в поток пользовательского интерфейса.

Answer 2

Я не знаю ни одного случая, когда атрибут [STAThread] заставил бы поток иметь более высокий приоритет.

Из этого SO вопроса , в котором рассматриваются различия между потоками STA и MTA:

Модель потока COM называется «квартира» модель, где исполнение контекст инициализированных объектов COM связан либо с одним потоком (Однопоточная квартира) или много темы (Multi Thread Apartment). В эта модель, объект COM, один раз инициализируется в квартире, является частью этой квартиры на срок это время выполнения.

Модель STA используется для COM-объектов. это не потокобезопасно. Это означает они не справляются со своими синхронизации. Обычное использование этого является компонентом пользовательского интерфейса. Так что если другой поток должен взаимодействовать с объект (например, нажав кнопку в форма), то сообщение отправляется на нить STA. Формы окон система прокачки сообщений является примером этого.

Если COM-объект может обрабатывать свой собственный синхронизация, то модель MTA может использоваться там, где несколько потоков разрешено взаимодействовать с объектом без маршалловых звонков.