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

Мне приходит в голову, что должны быть хорошие и плохие способы ожидания внешнего события внутри потока. Является ли этот подход ресурсоемким ?:

send command ;
repeat
until response arrived ;
process response ;    

и делает ли этот подход более эффективным?

send command ;
repeat
    Sleep (20) ;
until response arrived ;
process response ;  

* ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ *

Среда x86 для Windows XP. Код потока представляет собой длинную и сложную серию взаимодействий с последовательным устройством, но в целом он состоит из записи символов в COM-порт (с использованием последовательной библиотеки AsyncFree) и ожидания возврата символов путем размещения в буфере входящих символов и обрабатывая их, когда они прибывают. Я представляю, что последовательная библиотека выполняет чтение и запись устройства. Время в потоке может составлять минуту или пару секунд, но большая часть этого времени тратится на ожидание символов, покидающих порт, или на ожидание символов ответа (скорость передачи данных низкая), отсюда мой вопрос о том, как лучше вести поток, пока он ждет. В настоящее время я звонюSleep в цикле ожиданияCharactersInBuffer чтобы стать ненулевым, обрабатывать каждый символ, когда он прибывает, и выходить из потока, когда у меня есть полный ответ. Таким образом, код выглядит примерно так (без учета обработки тайм-аутов и т. Д.):

send command ;
Packet = '' ;
repeat

    repeat
        Sleep (20) ;
    until response character arrived ;
    build Packet

until complete packet arrived
process response ;