In welche Fallen tappen Software-Entwickler gemeinhin, wenn sie versuchen, seriell programmierte Anwendungen zu parallelisieren?

Gibt es Fälle, in denen es keinen Sinn macht, Teile einer Software-Anwendung zu parallelisieren?

Existieren gute Beispiele für erfolgreiche und erfolglose Versuche, bestehenden Code zu parallelisieren?

Na, dann viel Spaß mit dem Videointerview!

Der Beitrag Programmiermodelle für moderne Mehrkernarchitekturen geht ganz rudimentär auf die verschiedenen Ansätze ein, wie aus sequentiell programmierten Anwendungen parallel ablaufende Applikationen werden. Dabei zeigt der Autor die Unterschiede auf, die es unter anderem bei OpenMP, Thread-Bibliotheken, Java, C# zu berücksichtigen gilt. Ein guter Einstieg in die Welt der Parallelprogrammierung.

Der zweite Artikel setzt dort an, wo der erste quasi aufhört: bei einem dieser Modelle, und zwar OpenMP. Dabei will der Autor allerdings keine umfängliche Darstellung von OpenMP leisten, sondern den praktischen Nutzen darstellen. Dies geschieht mithilfe vieler nützlicher Beispiele. Und natürlich werden auch mögliche Stolperfallen wie Data Races besprochen.

Der dritte Artikel Parallelisierung mit der POSIX Thread Bibliothek beschäftigt sich mit einem Thema, das hochkomplex, aber auch sehr fundamental ist: Wie multithreade ich eine Anwendung mithilfe plattformunabhängiger Pthreads? Dieses Konzept ist zwar nicht mehr State-of-the-Art, bietet dafür aber die Möglichkeit, hochperformante, parallel ablaufende Anwendungen zu programmieren. Und das Verständnis rund um das Thema Parallelprogrammierung wird mithilfe der Pthread-Kenntnisse ebenfalls geschärft.

Tja, und auf den vierten Artikel habe ich bereits letzte Woche aufmerksam gemacht. Na dann, viel Spaß beim Lesen!

Für aufmerksame Leser des Software Dev Blogs werden sich nicht sonderlich viele Neuigkeiten aus dem Beitrag ableiten lassen, aber in seiner Abgeschlossenheit trägt der Artikel doch sehr zum Verständnis von Parallel Studio bei. Zudem handelt es sich um ein PDF-Dokument, das sich sogar ausdrucken lässt. Für die analogen Zeitgenossen unter uns.

Der Artikel umfasst drei Seiten und geht recht detailliert auf die einzelnen Komponenten ein, also Parallel Composer, Parallel Inspector und Parallel Amplifier. Lustigerweise beginnt der Beitrag mit dem Parallel Advisor. Dieses Tool wird erst in der nächsten Version zum Parallel Studio gehören, kann allerdings heute schon als eine Art Techdemo kostenlos ausprobiert werden.

Schön an dem Parallel-Studio-Beitrag sind die praxisorientierten Einblicke, die man anhand der eingefügten Bilder gewinnen kann. Schade ist allerdings, dass diese teilweise recht klein geraten sind. Und ein, zwei Codebeispiele hätten dem Artikel zu ein wenig mehr Pfiff verholfen. Na ja, beim nächsten Mal dann, ok?!

Zunächst einmal kann man festhalten, dass die Thread-Synchronisierung im .NET-Framework ähnlich funktioniert wie im Win32- oder Pthreads-Umfeld. Es geht also um den gegenseitigen Ausschluss sowie um atomare Aktionen auf spezielle Variablen. Wie bei der von C# bekannten Methode lock wird ein Codeabschnitt mithilfe der geschweiften Klammern geblockt, sodass zu dieser Zeit nur ein einziger Thread darauf zugreifen kann. Hierfür bietet das .NET-Framework eine ähnliche Konstrukte:

Monitor.Enter ( this )
try
{
……. shared_var = other_shared_var +1;
……. other_shared_var = 0;
}
finally
{
…… Monitor.Exit ( this )
}

Mit der Klasse Monitor wird der entsprechende Codeabschnitt blockiert. Mit Enter() wird der Abschnitt gesperrt und mit Exit() wieder freigegeben. Praktisch an Monitor ist auch dessen Möglichkeit, Datenstrukturen als Parameter zu übergeben.

Bei Monitor.Enter() geschehen übrigens zwei Dinge: Erstens wird eine Warteschlange eingerichtet, die auf diejenigen Threads verweist, die gesperrt werden sollen und eine zweite Queue mit Threads, die darüber informiert werden wollen, wenn eine Speere verfügbar ist. Monitor.Exit() sorgt dafür, dass der erste verfügbare Thread in Warteschlange #1 gesperrt wird.

Darüber hinaus hält die Klasse Monitor eine weitere Methode bereit: So lässt sich mit Monitor.Wait() die Sperre eines Threads auf einen anderen Thread übertragen, um die Sperre später wieder zurückzuverlangen. Ein Impuls benachrichtigt hierbei den ursprünglichen Thread darüber, dass die Sperre wieder aufgehoben wurde.

Neben den Monitor-Methoden lassen sich unter .NET auch Mutexe für das Sperren und Freigeben von Threads verwenden. Im Gegensatz zu der Monitor-Klasse werden Mutexe in Verbindung mit Handles eingesetzt und können zudem zudem für mehrere Sperren eingesetzt werden, die dann natürlich genauso oft wieder freigegeben werden.

private static Mutex mutx = new Mutex();
…

private static void UseResource()
{
……//Warten, um in den Sperrcode einzutreten
……mutx.WaitOne();

……Console.WriteLine( ” im gesperrten Modus “);

……Thread.Sleep( 100 ); // 100 Millisekunden warten

……Console.WriteLine( ” den gesperrten Modus wieder verlassen “);

……// Mutex wieder freigeben
……mutx.ReleaseMutex();

}

Atomare Aktionen
Unter atomaren Aktionen versteht man landläufig unteilbare Maschinenanweisungen, wie sie beispielsweise für Datenbankoperationen eingesetzt werden. Dabei ist es von essenzieller Wichtigkeit, dass mehrere dieser Teilschritte zurückgenommen werden können, falls der gesamte Schritt nicht beendet werden kann. Bei Threads verhält es sich ganz ähnlich: Variablen werden verändert und gleichzeitig geht beim Programmablauf etwas schief. Die Folge: Das System ist im schlimmsten Fall beschädigt oder Daten korrupt.

Um so etwas auszuschließen, hat Microsoft in das .NET-Framework die Klasse Interlock eingebaut, die drei wesentliche Methoden vorsieht: Decrement, Increment und Exchange. Diese sollten vor allem dann eingesetzt werden, wenn eine bestimmte Variable von mehreren Threads parallel genutzt wird:

int intCounter = 0;
…

Interlocked.Exchange( ref usingResource, 6 ); // Setze den Wert von intCounter auf 6

Interloced.Decrement( ref intCounter ); // Reduziere den Wert von intCounter auf 5

Interlocked.Increment( ref intCounter ); // Erhöhe den Wert von intCounter wieder auf 6

Beachtenswert ist die Tatsache, dass mit Increment und Decrement nicht die Variable selbst, sondern nur der Verweis darauf verändert wird (da es sich dank des Zusatzes ref um eine Art Zeiger handelt). Und Exchange ändert nicht die Werte, sondern initialisiert lediglich einen Wert mit einem anderen.

Zunächst einmal sollte man sich klar machen, dass das Erzeugen und Verwalten von .NET-Threads mit einem immensen administrativen Aufwand verbunden ist: Lokaler Thread-Speicher muss angelegt und die Systemstrukturen für die Thread-Verwaltung müssen eingerichtet werden. Darüber hinaus nimmt die Komplexität des Quellcodes deutlich zu, sobald mehrere Threads mit Bordmitteln verwaltet werden sollen.

Aus diesem Grund hat Microsoft dem .NET-Framework ein Ressource spendiert, die sich ThreadPool nennt. Dabei wird zunächst eine bestimmte Anzahl von Threads generiert, außerdem wird eine Art Arbeitswarteschlange erstellt. Sobald eine auszuführende Aufgabe in diese Warteschlange befördert wird, wird ein Thread für diesen Task aktiviert und ihm die Aufgabe zugewiesen. Dies erledigt das .NET-Framework automatisch. Allerdings ist dabei zu beachten, dass der ThreadPool nur dann sinnvoll eingesetzt werden kann, wenn ein Programm aus mehreren Threads besteht, die immer wieder benötigt werden.

Der Pool wird mithilfe der Anweisung ThreadPool.QueueUserWorkItem (new WaitCallback ( DELEGAT ) ) erzeugt, sobald die erste Aufgabe an die Warteschlange übergeben wird. Die Anzahl der im Pool erzeugbaren Threads ist unter .NET auf 25 pro Hardware-Prozessor begrenzt. Allerdings kann man mithilfe der Methoden GetMinThreads() und SetMinThreads() die minimale Anzahl von Threads abfragen bzw. erzwingen. Mit GetMaxThreads() lässt sich die maximale Anzahl von Threads bestimmen.

Mit den ThreadPools in .NET lassen sich aber nicht nur Aufgaben parallel ausführen, sondern auch asynchrones Warten erzwingen. So kann beispielsweise auf einen Datenanfrage innerhalb des Netzwerks reagiert werden. Hierfür ist eine sogenannte Callback-Funktion erforderlich, die beim Eintreten eines zu erwartenden Ereignisses aufgerufen wird. Eine dieser Funktionen nennt sich RegisterWaitForSingleObjekct(), die die Angabe einer maximalen Wartezeit erlaubt. Die Callback-Funktion wird aufgerufen, wenn das Ereignis eintritt oder die definierte Wartezeit abgelaufen ist.

Aber nicht nur einzelne Ereignisse können Threads starten, sondern auch eine ganze Reihe davon. Hierfür existieren die Methoden WaitHandle.WaitAll() und WaitHandle.WaitAny(), die ausgeführt werden, wenn alle Ereignisse oder irgendein Ereignis eintreten. Zudem lassen sich diese manuell mithilfe der Methode ManualResetEvent() zurücksetzen.

Beenden von Threads: Dies geschieht am einfachsten, indem ein Thread ganz regulär während des Programmablaufs verlassen wird und die Anwendung wieder zum Masterthread zurückkehrt. Dies gibt der Common Language Runtime (CLR) die Möglichkeit, die notwendigen Aufräumarbeiten durchzuführen. Allerdings muss manchmal ein anderer als der gerade laufende Thread beendet werden. Daher hat Microsoft den .NET-Thread-APIs eine Methode spendiert, die sich Abort() nennt, mit deren Hilfe ein laufender Thread abgebrochen werden kann. Beim Aufruf von Abort() wird automatisch eine ThreadAbortException ausgelöst.

Der Aufruf von Abort() zieht übrigens eine Reihe verschiedener Dinge nach sich. Dazu gehört die Fähigkeit des Threads, den eigenen Abbruch zu vereiteln, indem er innerhalb des Exception-Handlers die Methode System.Threading.Thread.ResetAbort aufruft. Daneben besteht die Möglichkeit, innerhalb eines Codeblocks mithilfe von finally weiteren Quellcode ausführen zu lassen, was im ungünstigsten Fall eine beachtliche Verzögerung des Thread-Abbruchs nach sich zieht. Aus diesen beiden Gründen sollte man zur Laufzeit überprüfen, ob ein bestimmter Thread auch vollständig abgebrochen wurde. Hierfür steht die Join-Methode zur Verfügung.

Auf einen Thread warten: Die parallele Ausführung mehrerer Threads innerhalb eines Programmes bringt es zwangsläufig mit sich, dass Threads immer wieder aufeinander warten müssen. Um dies zu erreichen, hat Microsoft dem .NET-Framework die Thread-Methode Join() verpasst, was ein Zusammenführen zweier Threads bedeutet. In der Konsequenz heißt das, dass ein Thread mit seiner Fortsetzung so lange wartet, bis ein vorhergehender Thread fertig ist. Da dies zu unliebsamen Nebeneffekten führen kann (Stichwort: Dead Lock), besteht die Möglichkeit, Join() einen Parameter zu übergeben, der einen Integerwert darstellt. Dieser Wert besagt, wie lange gewartet werden soll, bis der Vorgänger-Thread (voraussichtlich) beendet wird. Das Ergebnis von Join() ist ein boolscher Wert, der true (Thread beendet) oder false (Thread nicht beendet) annehmen kann.

Threads anhalten und fortsetzen: Im Gegensatz zur Methode Sleep(), mit der ein Thread für eine festgelegte Zeitdauer angehalten und automatisch fortgesetzt wird, besteht eine weitere Möglichkeit, einen Thread auf unbestimmte Zeit zu stoppen und zu einem späteren Zeitpunkt wieder aufzunehmen. Die hierfür zuständigen Methoden nennen sich Suspend() und Resume(). Beiden Methoden kann kein Argument übergeben werden und beide liefern auch keinen Rückgabewert.

Das alles werde ich ab heute in Form einer Miniserie mit der Überschrift “Alles über .NET Threads” nachholen. Der erste Teil beschäftigt sich mit dem Thema “Threads erzeugen”.

Da die .NET-APIs etwas “schlanker” sind als ihre Win32-Brüder und -Schwestern, gestaltet sich das Erzeugen eines .NET-Threads relativ einfach. Dies sieht wie folgt aus:

using System.Threading;

[Definition von Variablen]

Thread t = new Thread( new ThreadStart( ThreadFunc ));

Der Aufruf von ThreadStart() erzeugt einen neuen Thread. Der Parameter ist eine Delegat namens ThreadFunc. Übrigens: In C# ist ein Delegat identisch mit der Adresse einer Funktion in C. Der Thread endet dann an der Stelle, sobald ThreadFunc() endet. Doch damit nicht genug. Für eine fehlerfreie Ausführung des Threads muss weiterer Code implementiert werden:

t.Start() — Dies startet den Thread unter .NET explizit (was z. B. unter Win32 nicht erforderlich ist).

Thread.Sleep( 40 ) — Dies unterbricht den (seriellen) Hauptthread für die Dauer der Zeiteinheit in der Klammer, die in Millisekunden angegeben wird. Dies kann in der Praxis jedoch erheblich von der tatsächlich benötigten Zeit abweichen.

[aufzurufende Funktion] — Diese Funktion wird parallel auf den vorhandenen Prozessorkernen ausgeführt.

Thread.Sleep( 0 ) — Dies beendet den parallelen Thread und reaktiviert den “schlafenden” Hauptthread.

Besonders bemerkenswert daran fand ich übrigens die Seite, die den Beitrag verlinkt hat: Es handelt sich um niemand geringeres als MSDN, also das Entwicklerportal von Microsoft, die dem Thema Parallele Programmierung eine eigene Webseite spendiert haben. Und genau dort findet man den Link auf meinen OpenMP-Beitrag. Daneben gibt es noch weitere interessante Einstiege in die Welt der Multithreading-Entwicklung. Da erfährt man eine Menge über die Grundlagen der Parallelprogrammierung, aber auch Tools und Downloads werden dort vorgestellt.

Des Weiteren können interessierte Entwickler nützliche Artikel abgreifen, Webcasts und Videos angucken und Blogs lesen. Und klar, dass es auf der Webseite auch um die Themen Paralleles Programmieren mit .NET geht. Besonders bemerkenswert finde ich auch die Tatsache, dass MSDN für Intel eine eigene Sektion mit Namen “Intel Developer Network” spendiert hat. Dort findet man Wissenswertes zum Parallel Studio und zu anderen Themen.

Fazit: Parallel Computing auf MSDN ist eine bookmark-taugliche Webseite, wenn man in Sachen Parallele Programmierung auf dem Laufenden bleiben will.

Im ersten Schritt wird beispielsweise vom Thread Manager ein Thread erzeugt und in den Bereit-Zustand versetzt (“ready”). Dort verharrt der Thread so lange, bis er eine Anweisung, eine Funktion oder ähnliches ausführen soll. Darum kümmern sich entsprechende Programmanweisungen wie zum Beispiel die Pragma-Methoden der OpenMP-basierten Programmierung.

Im zweiten Schritt kommt es zur Ausführung der entsprechenden Quellcodestelle. Währenddessen muss der betreffende Thread möglicherweise auf einen anderen Thread oder ein Datum eines parallel ablaufenden Threads warten. Dann begibt er sich in den Wartend-Modus, bis der benötigte Thread beendet ist oder dessen Ergebnis vorliegt. Anschließend wird der angehaltene Thread weiter ausgeführt oder wieder in den Bereit-Zustand versetzt, da der Thread zu einem späteren Zeitpunkt nochmals benötigt wird.

Ach ja: Gerade dieser Wartend-Modus bereitet vielen Programmierern erhebliche Probleme, da hierbei Dead Locks, Data Races oder andere unvorhersehbare Ereignisse auftreten können. Wie gut, dass es hierfür Tools wie den Thread Checker oder Parallel Inspector gibt, die solche Schwachstellen aufspüren können.

Natürlich ist es auch möglich, dass ein Thread ausgeführt wird, ohne in den Wartend-Zustand versetzt zu werden. Dann stehen zwei Folgemodi zur Auswahl: Bereit oder Beendet. “Bereit” tritt immer dann ein, wenn der Thread nicht nur einmal, sondern mehrmals benötigt wird, was schon beim Programmdesign berücksichtigt werden muss. Dies kann beispielsweise eine Schleife sein, die mehrfach ausgeführt werden muss. In diesem Fall empfiehlt es sich, den zugehörigen Thread nicht zu beenden, sondern ihn wieder auf “Bereit” zu setzen, da das Erzeugen eines Threads relativ viel Rechenzeit und Verwaltungsaufwand bedeutet.

Sobald ein Thread nicht mehr benötigt wird, kann er natürlich auch beendet werden. Er wird dann aus dem Thread-Pool entfernt, alle Variablen werden gelöscht und der Thread steht nicht mehr zur Verfügung. Was aber nicht heißt, dass er zu einem späteren Zeitpunkt nicht wieder erzeugt werden kann.

Übrigens: Zu Beginn einer parallelisierten Anwendung wird ein sogenannter Initial Thread initiert, der den sequeziellen Programmablauf steuert und der auch dafür zuständig ist, das Programm “am Leben zu erhalten”, während zur Laufzeit immer wieder neue, parallel ausfühbare Threads erzeugt werden. Sobald dieser Initialisierungsthread beendet wird, endet auch das komplette Programm.

Tasks sind die zentralen Elemente der Parallel Extensions, also dedizierte Aufgaben, Funktionen, Schleifenkonstrukte oder ähnliche Dinge. Eine Task führt stets eine Funktion oder ein anderes Konstrukt innerhalb eines Threads aus, um so eine optimale Ausnutzung der Systemressourcen zu erzielen.

Das Besondere daran sind die Call-Back-Funktionen, die es ermöglichen, bestimmte Dinge zu übergeben, die in einem separaten Thread ausgeführt werden sollen. Mithilfe der Tasks müssen Anwendungsprogrammierer also nicht mehr in Threads denken, da diese von den .NET-Tools automatisch erzeugt, verwaltet und auf die vorhandenen Ressourcen verteilt werden.

Daneben gibt es Futures, also Tasks mit Rückgabewerten. Solch ein Future-Konstrukt führt beispielsweise in einem eigenen Task eine Funktion aus, deren Ergebnis an das Hauptprogramm übergeben wird, das währenddessen weiterrechnen kann. Zwar muss das Programm an einer bestimmten Stelle auf das Ergebnis warten, kann aber trotzdem parallel andere Aufgaben ausführen. Eine weitere simultane Ausführungsoption ist die Methode Parallel_Invoke(), die einen ganzen Satz von Methoden zugleich abarbeiten kann, sofern diese voneinander unabhängig sind.

Aber auch Schleifenkonstrukte bieten sich für die parallele Programmierung an, da hier gerechnet wird, was mithilfe einer parallelen Ausführung erheblich beschleunigt werden kann. Der große Vorteil von parallelen Schleifenkonstrukten ist deren fehlende Abhängigkeit von globalen oder lokalen Variablen, die bei der sequenziellen Ausführung entstehen. Ebnenso eignet sich der parallele Datenzugriff (beispielsweise bei Datenbankanwendungen) sich bestens zum Parallelisieren.

Als Beispiel dient eine Matrixoperation, die mit drei Variablen arbeitet, die bei der sequenziellen Programmierung mithilfe eines dreifach-verschalteten Schleifenkonstrukts das Ergebnis der Matrixberechnung ermittelt. Bei der parallelen Schleife Parallel.For() hingegen wird nur die äußere Schleife initiiert, die zwei inneren Schleifen werden per Methode übergeben. Im Hintergrund werden dann die zwei “inneren Schleifen” auf zwei parallele Threads verteilt. Die Daten werden dann am Schluss automatisch zusammengeführt. Und so sieht der Quellcode dazu aus:

Eine weitere Kernfunktion des .NET-4.0-Frameworks ist die Taksmanager-Klasse, die sich um die optimale Auslastung der Systemressourcen, sprich Prozessoren und CPU-Kerne, kümmert. Hierfür versucht der Taskmanager stets, die notwendigen WorkerThreads gleichmäßig mit Tasks zu bestücken. Das geht sogar so weit, dass “unterbeschäftigte” WorkerThreads einzelne Tasks von “überbeschäftigten” WorkerThreads erhalten, um so ein optimal ausgelastetes System zu garantieren. Die Strategie dahinter nennt sich “Work Stealing”. Der Taskmanager ist übrigens beliebig konfigurierbar und ermittelt unter anderem die vorhandene Anzahl an Prozessoren.

Aber nicht nur die Parallelisierung von Berechnungen, sondern auch der simultane Datenzugriff wird bei .NET 4.0 im Vordergrund stehen. Hierfür wird die seit .NET 3.5 verfügbare Spracherweiterung LINQ (Language Integrated Query) parallelisiert, woraus PLINQ entsteht. Mit PLINQ kann man typsicher auf bestimmte Behälterklassen zugreifen, also auf Arrays, Listen, Queues oder Hashtabellen. Diese Datenzugriffe erinnern an die Abfragekonstrukte von relationalen Datenbanken.

Mit SQL-ähnlichen Abfragen und Konstrukten lässt sich beispielsweise möglichst schnell und simultan nach einem bestimmten Namen suchen. Dies gilt zumindest für große Datensätze. Sind nämlich nur wenigen Daten vorhanden, entpuppt sich die Parallelisierung oft als kontraproduktiv, da der notwendige Overhead die Berechnung eher ausbremst als beschleunigt.

Im einleitenden Teil habt ihr unter anderem erfahren …

… warum es mittlerweile mehr Anstrengungen erfordert, bestehende oder neue Anwendungen auf vorhandenen Computerplattformen schneller zu machen,

… was die Gesetze von Amdahl und Gustafson für die parallele Programmierung bedeuten

… und auf welchen Elementen moderne Programmarchitekturen basieren.

Im heutigen zweiten Teil geht es ans Eingemachte: Welche Hürden sind bei der Multicore-Programmierung im .NET-Umfeld zu überwinden? Welche Tools gibt es bereits dafür? Und was kommt auf die Entwickler in den nächsten Monaten noch alles zu?

Die gute Nachricht: Multithreading wird mittlerweile von den nativen Programmiersprachen wie C++ und Fortran bestens unterstützt. Hierfür gibt es auch diverse Tools wie Threading Building Blocks, Thread Checker und OpenMP, die Entwickler für die Parallelprogrammierung einsetzen können. In Sachen C#, Java und Python sieht es zwar (noch) nicht ganz so gut aus, aber es gibt bereits einige Methoden, Multithreading in .NET-Applikationen zu realisieren. Dabei handelt es sich um Konstrukte zum Erzeugen und Synchronisieren von Threads, aber auch zum Sperren von gemeinsamen Ressourcen (Speicher) und zum Verwalten von Threadpools.

Nichtsdestotrotz gibt es beim Multithreading diverse Probleme, mit denen sich Programmierer ohne die passende Unterstützung durch Tools oder das Framework herumschlagen müssen. Hierzu zählen unter anderem Race-Conditions, Deadlocks und ein inkonsistentes Sperren von gemeinsamen Ressourcen. Die Performance leidet ebenfalls unter unzureichendem oder falschem Multithreading. Dies betrifft zum Beispiel das übertriebene Sperren von gemeinsamen Speicherbereichen sowie die vernünftige Lastverteilung auf die vorhandenen Prozessoren. Stichwort automatische Skalierung von Anwendungen auf unterschiedlichen Plattformen.

Doch zurück zur guten Nachricht: Es gibt Methoden, um in .NET-Umgebungen Multicore-Anwendungen mit relativ wenig Aufwand zu schreiben. Das Zauberwort: ThreadPool-Klassen. Diese eignen sich vor allem für asynchrone Aufgaben, die mithilfe der BackgroundWorker-Klasse auf einen eigenen Thread, sprich Prozessorkern, ausgelagert werden können. Ein Beispiel hierfür ist die Benutzeroberfläche, die einem dedizierten Thread zugeordnet wird. Parallel dazu läuft das Programm weiter, ohne dass es zu Leistungseinbußen kommt.

So viel zur Gegenwart. Die Zukunft sieht aber noch viel mehr vor. Denn eines ist klar: An der Multithread-Programmierung werden .NET-Entwickler bald nicht mehr vorbeikommen. Aus diesem Grund wurde die Microsoft Parallel Computing Initiative ins Leben gerufen, die ein klares Ziel verfolgt:

Vereinfachte Entwicklung paralleler Programme auf der Microsoft Windows Plattform, die korrekt, effizient und wartbar sind, für alle Software-Entwickler.

Daraus sollen drei Dinge resultieren:

• Software-Entwickler können .NET-Programme einfacher parallelisieren, um sich besser auf die eigentliche Problemlösung zu konzentrieren.

• Die Effizienz und Skalierbarkeit paralleler Anwendungen kann gesteigert werden.

• Der Entwurf und Test paralleler Programme wird vereinfacht.

All diese Forderungen münden in den Parallel Extensions (auch PFX genannt), die in das .NET-Framework Version 4.0 implementiert sein werden. Die PFX-Erweiterung zeichnet sich durch folgenden Merkmale aus:

• Die Parallel Extensions stellen eine Bibliothek dar, erfordern also keine Modifikationen am jeweiligen Compiler.

• Sie sind sehr “leichtgewichtig”, da sie im Benutzermodus laufen.

• Es wird deklaratives und imperatives Parallelisieren unterstützt. Für die imperative Aufgabenparallelität ist die Task Parallel Library zuständig, um die deklarative Datenparallelität kümmert sich PLINQ.

• Es wird ein gemeinsames Exception-Handling-Modell geben, da die Ausnahmebehandlungen bei parallelen Programmen anders aussehen als bei seriellem Quellcode.

Und was bringt das Ganze? Nun, PFX bietet eine überschaubare Anzahl von Konzepten und reduziert zudem die Komplexität paralleler Programmierung. Denn das erklärte Ziel ist es ja, Anwendungsprogrammierern den Zugang zur Multithreading-Entwicklung so einfach wie möglich zu machen. Für bessere parallelisierte Programme.

Übrigens: Wer sich Visual Studio 2010 und das zugehörige .NET-Framework 4.0 schon mal ansehen will, kann sich auf eigene Gahr die CTP-Version auf seinen Rechner laden. Und wer noch mehr zum Thema paralleles Programmieren unter .NET wissen will, sollte am Montag hier wieder vorbeikommen …

Die Session gliederte sich in vier Abschnitte: Einleitung, Parallelisierung durch Multithreading, neue Konzepte in .NET 4.0 und Ausblick. Die Zusammenfassung verschweige ich einfach mal.

Der erste Teil “Einleitung” beschäftigte sich vor allem mit der Frage, warum das kostenlose Mittagessen vorbei ist. Dies ist die zugegebenermaßen schwachsinnige Übersetzung eines englischsprachigen Artikels, der sich mit der Tatsache beschäftigt, dass Prozessoren seit Jahren nicht mehr schneller werden (sondern eher langsamer) und man daher als Entwickler keine Geschwindigkeitszuwächse mehr erwarten kann, die quasi kostenlos für mehr Leistung sorgen, ohne dass man hierfür am Quellcode herumschrauben muss. Das heißt dann im Umkehrschluss, dass sich Programmierer in Zukunft intensiv mit dem Thema Parallelprogrammierung auseinandersetzen müssen, um aus den künftigen Multicore-Prozessoren das Optimum herauszuholen.

Um die möglichen Schwierigkeiten der Parallelprogrammierung zu verdeutlichen, wies Rohe zunächst auf die Architektur des Core 2 Duo Prozessors von Intel hin, der aus zwei Kernen mit einem eigenem L1-Cache besteht, aber zudem über einen gemeinsamen L2-Cache verfügt. Und genau das stellt eine der wesentlichen Herausforderungen der Parallelprogrammierung dar: der gemeinsame Speicherzugriff mit all seinen unvorhersehbaren Verklemmungen und Problemen!

Über die Grenzen der Parallelisierung sprach Rohe natürlich auch, und zwar mithilfe des Amdahlschen Gesetzes, das eher pessimistisch ausgelegt ist. Tenor von Amdahl, einem amerikanischen Computerarchitekten: Je höher der Anteil an sequenziellem Quellcode innerhalb einer Anwendung ist, desto weniger profitiert eine Anwendung von der Parallelisierung. Dies kann laut Amdahl so weit gehen, dass selbst eine große Zahl an Prozessorkernen keinen nennenswerten Geschwindigkeitszuwachs mit sich bringt – allen Parallelisierungsanstrengungen zum Trotz.

Aber es gibt auch das Gesetz von Gustafson, das viel optimistischer als das von Amdahl ausgelegt ist. Gustafson kam im Zuge seiner Studien zu dem Schluss, dass die Parallelisierung von der verfügbaren Zahl der Prozessorkerne abhängt. Ergo: Je mehr CPUs vorhanden sind, desto besser skaliert die parallelisierte Anwendung.

Seine Einleitung schloss Rohe mit der Unterscheidung von Agenten, Aufgaben und Daten, auf denen jede Programmarchitektur basiert. Das Wissen um diese drei Programmpfeiler ist für das Verständnis der parallelen Programmierung von elementarer Wichtigkeit.

Programmhinweis: Die Teile zwei und drei sowie die Zusammenfassung gibt es morgen hier auf diesem Kanal. So, stay tuned. Am besten, ihr abonniert das Blog einfach als RSS-Feed. Oder lasst euch neue Beiträge via Feedburner in die Inbox eures Mailprogramms schicken.

Teil zwei unserer kleinen Vorstellungsrunde „Was findet hier eigentlich statt?“ beschäftigt sich mit dem Thema Virtualisierung. Dass es sich hierbei um einen Begriff handelt, der sehr unterschiedlich genutzt wird, macht es nicht wirklich leichter. Wir wollen aber trotzdem versuchen, uns dem Thema ein wenig anzunähern.
Ein guter Start in die virtuelle Intel-Welt ist die Webseite Intel Virtualization Developer Community, auf der es eine Menge an nützlichen Infos zu entdecken gibt. Dazu gehören unter anderem Hintergrundinformationen rund um das Thema Virtualisierung: Warum Software-Entwickler die Virtualisierung ernst nehmen sollten, Vorteile der Virtualisierung in großen Unternehmen, Software-Design für virtualisierte Rechner und was hinter der Intel Virtualization Technology (Intel VT) steckt.

Was aber hilft die ganze Theorie, wenn die Praxis nicht zu Wort kommt. Daher darf natürlich nicht der Hinweis auf existierende Blogs und Foren fehlen, in denen Virtualisierungsexperten einerseits und Entwickler andererseits Tipps geben, über ihre Erfahrungen berichten und einfach nur helfen wollen. Außerdem gewähren beispielhafte Anwendungen tiefer gehende Einblicke in das Thema Virtualisierung.

Natürlich will und wird das Software Dev Blog all das ebenfalls leisten: Einblicke verschaffen, Antworten geben und die Community näher zusammenbringen. Wir freuen uns auf Ihre Teilnahme!

Den Anfang macht Visual Computing. Hier geht es vor allem um eins: Spaß! Zumindest, wenn man sich in der Gaming-Ecke aufhält und stets mit den neuen aufregenden Spieletiteln zu tun hat, mit denen sich Intel und deren Software-Partner (ISV = Independent Software Vendor) den ganzen Tag beschäftigen. Dabei lassen zwei große Trends erkennen: mobiles Gaming-Erlebnis und Multi-Threading.

3D-Spiele auf einer mobilen Plattform sind laut Heiko Tom Felde, Managing Director von Ascaron, das nächste große Ding. Er muss es wissen, schließlich zeichnet sich seine Firma für das Adventure-RPG-Game Sacred 2 verantwortlich. Sacred 2 wurde als einer der ersten Spieletitel überhaupt für die Centrino-2-Plattform von Intel optimiert und deren integrierte Grafikeinheit GMA X4500.

Damit läuft ein aufwendig gestaltetes RPG erstmals auf einem Notebook, da die notwendigen Berechnungen, das 3D-Rendering und andere relevante Komponenten auf die mobile Plattform zugeschnitten sind. Und dass Sacred 2 auf einem Montevina-Laptop gut aussieht, davon konnten wir uns auf der GCDC’08 selbst überzeugen – wir waren ziemlich begeistert.

Das Thema Multi-Threading ist ebenfalls ein wichtiges Thema bei den Jungs und Mädels der Visual Computing Group. Oder anders ausgedrückt: Wie optimiere ich meinen DirectX- und OpenGL-basierten Content so gut wie möglich für Intel-Prozessoren und wie gelingt es mir, Highend-Anwendungen wie Autodesk oder eine Echtzeit-Simulation der Meere für eine Vielzahl von Prozessoren zu parallelisieren?

Das Beste daran aber ist die Tatsache, dass man als unabhängiger Entwickler vor diesen Herausforderungen nicht allein steht. Dank des Software Partner Programms (SPP) kann man nämlich von Intels Expertise profitieren, indem man sich dem SPP anschließt und so eine bestmögliche Unterstützung erfährt. Und wer sich beeilt und dem SPP noch im Oktober beitritt, kann ein tragbares Solarladegerät gewinnen. Wenn das kein weiterer Anreiz ist …

Die Sektion Visual Computing beschäftigt sich mit allem, in dem das Kürzel „3D“ vorkommt. Klar! Bevorzugt also mit 3D-Spielen, aber natürlich auch mit Animations-Software wie Maya oder Architektenanwendungen wie AutoCAD. Dass in diesem Bereich insgesamt eine Menge Optimierungspotenzial steckt, davon konnten wir uns im August selbst ein Bild machen. Ich sage nur: Sacred 2, das dank der Optimierungskünste von Ascaron (und mithilfe von Intel) sogar auf einem Notebook mit integrierter Intel-Grafik flüssig läuft.

Das Thema Multicore hat ebenfalls viel mit optimiertem Programmcode zu tun: An welchen Schrauben muss ich drehen, damit meine Anwendung nicht nur auf einem Dual 2 Core eine angemessene Leistung bringt, sondern auch auf vier oder acht Prozessorkernen. Hierzu findet man auf der Multicore-Seite ganz viele Tipps & Tricks, aber auch Links zu nützlichen Tools und anderen Ressourcen. Sehr cool ist auch das BlogTalkRadio auf der Multicore-Seite. All diese Dinge wird es natürlich Stück für Stück auch auf dem Software Dev Blog geben.

Last but not least wird der Software Dev Blog vom immer wichtiger werdenden Thema Virtualisierung handeln. Hierzu findet man auf der US-amerikanischen Seite ebenfalls eine Menge an nützlichen Links: Was ist Virtualisierung, wie setze ich diese sinnvoll ein, welche Tools gibt es hierfür und was hat das alles mit Intel zu tun.

Sie sehen also, hier wird sich einiges tun in den nächsten Wochen und Monaten. Und wir haben nicht nur die pure Theorie im Visier: Natürlich sollen auch Entwickler zu Wort kommen, die gute Erfahrungen mit Intel in Sachen Developer-Support gemacht haben. Oder wir werden aussagekräftige Beispiele zu Rate ziehen, die das Optimierungspotenzial komplexer Software am besten demonstrieren. Oder …

Vielleicht fällt Ihnen ja ein weiteres „oder“ ein, das Sie gerne mit uns und allen Anwesenden dieses Blogs teilen wollen. Mailen Sie uns oder nutzen Sie die Kommentarfunktion. Wir freuen uns darauf!

BTW: Vom 10. bis 13. November werden wir live und in Farbe von der großen Microsoft-Entwicklerkonferenz Tech-Ed EMEA 2008 berichten. Lassen Sie sich überraschen …