Ich habe mal eine bessere Demoanwendung geschrieben:

Sie besteht aus einem Empfänger und einem Sender. Der Sender schickt eine Anforderung an den Empfänger, der daraufhin eine Listbox füllen soll. Auf dem Empfänger-Formular befinden sich sechs Listboxen, der Sender gibt dem Empfänger jeweils mit, welche Listbox gefüllt werden soll. Der Empfänger erzeugt dann entweder, je nach Auslastung, einen neuen Thread im Thread-Pool oder wartet bis ein Thread fertig ist und die Anforderung übernehmen kann.

Klicke ich zum Beispiel vier mal auf die Schaltfläche des Senders werden erst zwei Listboxen gefüllt und die verbleibenden zwei erst, wenn die Threads der ersten zwei Listboxen fertig sind. Dabei sollte man immer mal die Statusleiste des Empfängers beobachten, die die Anzahl der Threads anzeigt und gucken, wie die Listboxen gefüllt werden. Und wartet man bis die ersten Threads fertig sind und sendet dann eine weitere Anforderung, wird man sehen, dass keine weiteren Threads im Thread-Pool erzeugt werden.

Dann sollte man mal den Flag WT_EXECUTEDEFAULT durch den Flag WT_EXECUTELONGFUNCTION austauschen und wieder das Verhalten des Empfängers beobachten. WT_EXECUTELONGFUNCTION teilt dem System mit, dass der aufgerufene Thread etwas länger braucht bis er zurückkehrt, was das Erstellen von neuen Threads im Thread-Pool durch das System beeinflusst. Es neigt dann nämlich eher dazu einen neuen Thread zu starten.

Die Anzahl der Threads soll man so:
QueueUserWorkItem(@Thread, ThreadParams, WT_EXECUTEDEFAULT or 5 + $10000) beeinflussen können. In diesem Fall sollten jetzt nur maximal fünf Threads gestartet werden. Bei mir hat das aber noch nicht so ganz geklappt, glaube ich.

Demo im Anhang.