Teil 3: Programmieren für die Multi-Core-CPU

Verwaltung von Applikations-Threads

Die Verwaltung der Applikations-Threads durch den Thread Pool stellt nur eine von mehreren Varianten dar. Daneben könnte der Entwickler seine Applikations-Threads natürlich auch selbständig erzeugen und verwalten.

Die Nutzung des CLR Pools bietet aber entscheidende Vorteile: Sie entbindet den Entwickler von der expliziten Verwaltung der Threads und den notwendigen Start-, Stopp- oder Create- und Destroy-Operationen. Um all das kümmert sich nun die CLR von .Net. Dies erhöht auch die Effizienz in der gesamten Verwaltung.

Dennoch kommt der Entwickler nicht gänzlich um die eigene Thread-Verwaltung herum. Die Threads im Pool laufen immer als Hintergrund-Thread. Dementsprechend muss der Entwickler Threads, die im Vordergrund laufen sollen, selbst verwalten. Ferner erhalten die Threads im Pool eine Standardpriorität. Soll ein Thread eine andere Priorität aufweisen, muss er ebenso durch den Entwickler verwaltet werden.

Im .Net Framework Version 2.0 umfasst der Thread Pool standardmäßig 25 Worker Threads pro Prozessor and 1000 I/O Threads. Durch die Methode SetMaxThreads lässt sich die Anzahl der Threads im Pool aber verändern. Jeder Thread im Pool erhält außerdem einen Stack und eine Standardpriorität zugewiesen.

Zusammenspiel Vordergrund- und Hintergrund-Thread

Wenn die Applikation und ihre Vordergrund-Threads automatisch beendet werden sollen, sobald die Hintergrund-Threads ihre Arbeit erledigt haben, muss der Entwickler eigene Mechanismen dafür einsetzen, denn Hintergrund-Threads bleiben solange aktiv, wie der Vordergrund-Thread aktiv ist.

Somit kann also der Vordergrund-Thread nicht auf den Hintergrund-Thread und dessen Ende warten, um selbst die Arbeit einzustellen. Damit der Vordergrund-Thread dennoch erkennen kann, ob der Hintergrund Thread seine Arbeit erledigt hat, müssen Wait Handle Signale ausgetauscht werden.