InterThread Communication

Question

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

Формат файла сценария следующий.

CONNECT <www.abcd.com,80>
SEND :           AB 40 01 FF 00 00 00 09 01 01 07 00 00 C0 A8 01 87 AE 
MATCH<s,10>:     AB 40 01 FF 00 00 00 09 01 01 07 00 00 C0 A8 01 87 AE
SEND :       AB 34 01 FF00 00 00 0C 01 01 07 00 01 01 07 00 FF FF FF FF AE 
DISCONNECT
note: s in match is wait time in seconds.
here second byte is Msg ID.

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

У меня в приложении запущено два потока

1. Поток слушателя - он будет получать данные с сервера. (Здесь используется select ())
   он будет запущен, когда программа встретит команду connect, и завершится, когда
   встретится с разъединением в конфигурации.
2. основной поток, который будет читать команду из файла конфигурации и выполнять.

Теперь при обнаружении совпадения основной поток должен отправить строку сопоставления в поток прослушивателя для сопоставления и ждать там сигнала от потока слушателя.

Поток прослушивателя сопоставит строку с данными, полученными с сервера, если он совпадет, он выделит событие (окна SetEvent ()) для основного потока, а затем основной поток запишет «Соответствие найдено» другим образом, еслизатем он будет записан как «Соответствие не найдено»

Я думал о наличии глобальной переменной char * g_MatchString. Основной поток будет обновлять эту переменную всякий раз, когда есть команда соответствия, и ждать события (события Windows) длябудьте выделены, и время ожидания будет равно времени матча.

Мне, ребята, нужна информация о том, правильный ли мой подход.

Answer 1

Не используйте глобальный. Это просто создает потенциал для условий гонки, когда кто-то добавляет сложность в будущем. Соответствующая строка должна быть передана потоку в качестве входного аргумента. Вы не говорите, как запускаете поток, но если вы используете _beginthread (), вы просто выделяете буфер и передаете его _beginthread () в параметре arglist. Когда поток слушателя завершается, основной поток может безопасно освободить буфер строки соответствия. Это сохраняет его самодостаточным и свободным от возможных условий гонки, если когда-либо будут добавлены дополнительные потоки. Если вы запускаете поток с помощью CreateThread (), вы должны передать его через параметр lpParameter.

Кроме глобального, я думаю, что ваш подход обоснован.

Answer 2

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