Willst du in einem Thread warten, also ihn eine Zeitspanne stoppen, dan immer deine 2. Lösung benutzen. Das ist nicht nur eleganter (hat damit nichts zu tun) sondern es ist RICHTIGER !

Dein Event auf das er wartet wird in einer separaten Methode des Threadobjektes zb. .Stop; oder .Finish; etc.pp. ausgelöst und somit terminiert der Thread sofort und nicht erst nach X Millisekunden wie beim primitive Sleep().

Allerdings sollte es sogar so sein das du WaitForMultipleObjects() benutzt. Du benötigst dann Zugriff auf min. 2 Events gleichzeitig.

1.) dein Stop/Termierungs Event, so wie du es oben schon hast, um den Thread schnell und sauber zu terminieren.
2.) ein Data-Event. Also eigentlich ein Event das signalsiert das du nun mit ReadLn von zb. deinem Socket Daten abholen kannst.

In diesem Moment wartest du im WaitForMultipleObjects() immer INFINITE.

Erst DAS wäre eine absolut saubere Anwendung von Threads. Denn Threads habe auf einem Single-CPU Prozessor nur dann einen effektiven Nutzen wenn sie über die Events des OS signalisiert bekommen wann sie was abzuarbeiten haben, und ansonsten die meiste Zeit schlafen, also nichts an Rechenzeit kosten. Sockets, COM, USB usw. Treiber unter Windows unterstützen alle die Asynchrone Kommunikation per Events gesteuert (siehe Overlapping). Nur per Events und Threads kommt man vom Polling (als schechteste Alternative) weg.

Davon abgesehen kann das OS nur über diesen Weg auch eine saubere Synchronisation Threadübergreifend zur Verfügung stellen. Denn die Signalisierung eines Events arbeitet Hand in Hand mit den Synchronisationsobjekten unter Windows und auch dem Messagequeue.

Gruß Hagen