Dein Ansatz ist falsch, die Idee mit dem Suspend im Prinzip richtig, aber leider auch im Detail falsch.
Erstmal ist aber korrekt, das der eine Thread nun nicht non-stop per Critical-Section auf den geschützten Bereich zugreifen muss, denke ich. Normalerweise sehen Threads doch so aus
Willst Du z.B. ein Spiel programmieren, würde ein Timer dem Thread periodisch sagen können 'Do something': Der Thread erledigt diesen Job und wartet dann wieder auf den Nächsten. tigerman33 hat schon die Idee mit dem suspend gehabt, aber das ist unsauber, da man ja nicht weiss, was der Thread gerade macht. Besser ist es, über ein Synchronisationsobjekt mit dem Thread zu kommunizieren. Da wäre eine Semaphore oder ein Event gerade das Richtige. Die Funktion, die darauf wartet, das Synchronisationsobjekt (SO) ein Signal bekommt, heißt 'WaitForSingleObject' und... tut genau das: Es wartet, bis jemand das SO antriggert, und das sehr effizient (also mit 0% CPU-Last).

Ich arbeite mit Semaphoren. Eine Sempahore ist soetwas wie ein Zähler, der absolut threadsicher verwaltet wird. Wenn der Zähler 0 ist, dann wartet 'WaitForSingleObject' (WFSO). Sobald der Zähler>0, wird WFSO beendet und der Zähler um eins dekrementiert. WFSO wartet also, BIS der Zähler > 0 ist. Ist die Semaphore bereits > 0 beim Aufruf, wird die Semaphore sofort dekrementiert und WFSO beendet.

Die Semaphore wird mit 'ReleaseSemaphore' gesteuert.

Also:
1. CreateSemaphore im Create des Threads, CloseHandle im Destruktor.
2. WaitForSingleObject im Execute des Threads (lies genau die Möglichkeiten des Timeouts in der OH)
3. ReleaseSemaphore signalisiert, das der Thread einen Job zu erledigen hat.