Hardware-Strategien und Programmiermodelle

Eigenartigerweise ist Java von Sun vielleicht die einzige weit verbreitet eingesetzte Sprache, die auf Intel-Rechnern tatsächlich automatisch multithread-fähig ist, was vermuten lässt, dass es vielleicht noch Jahre dauern wird, bis die PC-Industrie die Hardware einholt, und dass der Einsatz von Intel vielleicht besser platziert ist, als es aussieht.

Obwohl es das Unternehmen als Langzeitstrategie in eine Sackgasse führt, funktioniert es als Kurzzeitstrategie: Gesunkene Kosten in Gewinne zu verwandeln und dabei zu versuchen, AMD und Microsoft anzutun, was AMD und Microsoft Intel angetan haben – und das schon zwei Mal. Das erste Mal passierte es, als Intel den Pentium Pro und echte 32-Bit-Verarbeitung in den Wintel-Markt einführte, bevor dieser Markt dazu bereit war. Das gab AMD die Möglichkeit, Marktanteile zu stehlen, indem das Unternehmen in seinen CPUs der K-Serie 16-Bit-Anweisungen beibehielt und somit ermöglichte, dass älterer Code auf AMD-Chips besser lief als auf Intels P II. Jüngst hat AMD natürlich den Weg für 64-Bit-x86 gebahnt, indem Nutzern die Möglichkeit eingeräumt wurde, alten 32-Bit-Code auf neuen 64-Bit-Rechnern auszuführen, was den Itanium 64-Bit-Chip von Intel so ziemlich vom Markt vertrieben und Intel in die Nachzüglerposition gedrängt hat, in der sich das Unternehmen heutzutage befindet.

In beiden Fällen war Microsoft von der Bildfläche verschwunden – zumindest aus der Sicht von Intel -, da man sich dort im Wesentlichen auf die Seite von AMD stellte, indem man die von Intel initiierte Veränderung nicht aktiv unterstützte. Diesmal allerdings setzt Intel auf die Erhaltung der Abwärtskompatibilität mit dem vom jetzigen x86er-Markt angenommenen Single-Thread-Verarbeitungsmodell, während man Microsoft halbherzig an der Heimunterhaltungsfront herausfordert.

Anders ausgedrückt, besteht die Strategie von Intel darin, zu hoffen, dass die Trägheit der Programmierer dafür sorgt, dass sich bestehende Programmiermodelle lange genug in der Hauptströmung über Wasser halten, bis ihnen selbst etwas eingefallen ist.

Man beachte, dass hier die Unix-Definition des Threads angenommen wird und nicht die von Microsoft. Genau gesagt ist ein Thread:

Eine Ablaufsteuerung innerhalb eines einzigen UNIX-Prozess-Adressbereichs. Solaris-Threads bieten eine Light-Weight-Form paralleler Tasks, indem in einem gemeinsamen Anwender-Adressbereich mehrere Kontrollthreads zugelassen werden, mit minimaler Belastung durch Scheduling und Kommunikation. Threads teilen sich denselben Adressbereich, Datei-Deskriptoren (wenn ein Thread eine Datei öffnet, können andere Threads sie weiterhin lesen), Datenstrukturen und Betriebssystemstatus. Ein Thread hat einen Programmzähler und einen Stapelspeicher, um den Überblick über lokale Variablen und Rücksprungadressen zu behalten. Threads kommunizieren durch die gemeinsame Nutzung von Daten und Thread-Synchronisierungsoperationen.

Ein Thread, der dauerhaft einem bestimmten Light-Weight-Process [LWP] zugewiesen ist, heißt „gebundener Thread“. Gebundene Threads können mit strikter Priorität in Beziehung zu allen anderen aktiven Threads im System auf Echtzeitbasis geschedulet werden, nicht nur innerhalb eines Prozesses. Ein LWP ist eine Einheit, die mit der gleichen Default-Schedulingpriorität wie jeder andere UNIX-Prozess geschedulet wird.

Obwohl Windows theoretisch eine im weitesten Sinne ähnliche Form des Threading bietet (Fibers genannt), finden diese scheinbar in Wirklichkeit nicht sehr häufig Anwendung. Stattdessen stehen fast alle Windows-Threads im Wesentlichen näher zu dem, was Unix einen ungebundenen Thread nennen würde: eine einzelne Ablaufsteuerung, der als Kontext ein einzelner LWP zugewiesen werden muss.