Multicore-Programmierung im .NET-Umfeld – Teil 2

Wie ich gestern versprochen habe, folgt heute der zweite Teil meines Mini-OOP-Specials zum Thema Multicore-Programmierung in der .NET-Welt.

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 …