Хорошее кодирование? (Несколько циклов сообщений)

Мне нужен какой-то совет в правильном кодировании:

Я работаю над программой, в которой используются несколько последовательных соединений. Каждая линия связи имеет контроллер, работающий как слой абстракции. Между контроллером и последовательным портом вставлен протокол для переноса данных в пакеты, готовых к передаче. Протокол заботится о неудачных поставках, повторении и т.д. Чтобы гарантировать, что GUI не будет висеть, каждая строка подключения (протокол и последовательный порт) создается в отдельном потоке. Контроллер обрабатывается основным потоком, так как он имеет элементы управления в графическом интерфейсе.

В настоящее время, когда я создаю потоки, я решил создать для них цикл сообщений (Application.Run()), поэтому вместо опроса буферов и получения, если нет работы, я просто вызываю поток (BeginInvoke) и использует цикл сообщений в виде буфера. В настоящее время это работает хорошо, и серьезных проблем пока нет.

Теперь мой вопрос: Является ли это "хорошим кодированием", или я должен использовать цикл while на протекторе и быть буферами опроса вместо?, или что-то третье?

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

Спасибо.

Ответ 1

Использование циклов сообщений в каждом потоке совершенно нормально; Windows оптимизирована для этого сценария. Вы правы, чтобы избегать опроса, но вы можете захотеть взглянуть на другие проекты на основе событий, которые более эффективны, например, для подготовки пакета для передачи и вызова SetEvent для уведомления о потоке, который он готов, или семафоре и потокобезопасном как говорит Мартин Джеймс.

Ответ 2

Я не уверен на 100%, что вы здесь делаете, но с небольшим количеством "заполнения" это не звучит плохо:)

Когда ваше приложение не работает, (нет сообщений), используется ли CPU 0%?

Является ли ваше приложение свободным от сна (0)/спящего режима (1) или схожими петлями опроса?

Работает ли он с достаточно низкой задержкой?

Если ответы три "ДА", вы должны быть в порядке:)

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