Qual é a maneira mais eficiente de CPU de "perder tempo" em um threa

Tenho um número de threads (100) que são executados por alguns segundos por vez. Quando estão em execução, gastam uma quantidade significativa desse tempo aguardando uma resposta de outro sistema (um dispositivo serial). Estou ciente de que ter 100 threads em execução ao mesmo tempo pode ser um recurso pesado, então, na verdade, limite o número de threads que podem iniciar a qualquer moment

Ocorre-me, no entanto, que deve haver maneiras boas e ruins de aguardar um evento externo dentro de um thread. Essa abordagem exige muita CPU:

send command ;
repeat
until response arrived ;
process response ;    

e essa abordagem a torna mais eficiente?:

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

* INFORMAÇÃO ADICIONAL

O ambiente é x86 no Windows XP. O código do encadeamento é uma série longa e envolvida de interações com um dispositivo serial, mas, em geral, consiste em gravar caracteres em uma porta COM (usando a biblioteca serial AsyncFree) e aguardar o retorno dos caracteres acampando no buffer de caracteres recebidos e processando-os quando chegarem. Imagino que a biblioteca serial faça leituras e gravações de dispositivos. O tempo no encadeamento pode ser de até um minuto ou de alguns segundos, mas a maior parte desse tempo é gasta aguardando os caracteres saírem da porta ou aguardando os caracteres de resposta (a taxa de transmissão é lenta), portanto, minha pergunta sobre a melhor maneira de o thread se comportar enquanto espera. Atualmente estou ligando paraSleep em um loop aguardandoCharactersInBuffer para se tornar diferente de zero, processando cada caractere quando chegar e saindo do encadeamento quando tiver a resposta completa. Portanto, o código se parece mais (ignorando a manipulação de tempos limite etc.):

send command ;
Packet = '' ;
repeat

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

until complete packet arrived
process response ;  

questionAnswers(3)

yourAnswerToTheQuestion