Die gute Nachricht vorweg: die Sessionplanung scheint abgeschlossen zu sein und die Programmübersicht listet genau 50 Voträge auf, die an zwei Tagen auf je vier Tracks und vier Themenbereiche verteilt sind. Hierzu gehört auch die Begrüßung am ersten Tag und – jetzt kommt’s – eine Abschluss-Keynote vom Content Manager der Veranstaltung höchstpersönlich, Golo Roden. So gesehen ist mein Wunsch nach einer Keynote ja erfüllt worden, allerdings nicht für den Beginn, sondern für das Ende der .NET DevCon. Na, soll mir auch recht sein!

Die abschließende Keynote-Session wagt einen Blick in die Zukunft zugleich. Denn unter dem Titel “C# 4.0 and beyond” stellt Golo einige der Features vor, die in C# 5.0 implementiert werden sollen. Diese hat ja C#-Oberchefentwickler Anders Heijlsberg auf der PDC 2010 ausführlich dargestellt.

Eine der Hauptunterschiede zwischen C# 4.0 und C# 5.0 wird die Realisierung der asynchronen, sprich der nebenläufigen, also der Parallelprogrammierung sein. So geschieht unter .NET 4 das Verteilen mehrerer Threads auf die vorhandenen Prozessoren mithilfe von Klassenbibliotheken. Auf Basis von C# 5.0 hingegen soll das mit einer angepassten Sprachsyntax geschehen, wovon sich Microsoft eine deutliche Erleichterung der asynchronen Programmierung verspricht.

Hierfür wird es in C# 5.0 das neue Schlüsselwort async geben, das auf die Verwendung asynchroner Methoden hinweist. Daneben wird in C# 5.0 mit await ein neuer Operator eingeführt, der das Programm dazu bringen soll, eine asynchrone Methode auszuführen. Diesen asynchronen Methoden wird auch eine neue Klassenbibliothek spendiert, die sich Task<T> nennt und die für die Rückgabewerte einer Methode zuständig sein wird.

Natürlich werden die neuen asynchronen Methoden von C# 5.0 Fehler abfangen können, und das auf Basis von Try-Catch-Konstrukten. Darüber hinaus lassen sich mithilfe der unter C# 4.0 eingeführten CancellationTokenSource-Klasse Hintergrundprozesse abbrechen.

Tja, über all diese Dinge und sicherlich noch weit mehr wird Golo am 7. Juni auf der .NET DevCon von 17:15 bis 18:15 Uhr reden. Da kann man schon sehr gespannt sein!

Ach ja: Windows Phone 7 hat es leider doch nicht auf die .NET DevCon geschafft. Na, wozu gibt es die erst gestern vorgestellt Mobile DevCon?!

Und für alle, die sich die PDC-2010-Session von Anders Heijlsberg zu C# 5.0 anschauen wollen, haben wir das zugehörige Video verlinkt. Viel Spaß dabei!

Das Erfolgsgeheimnis: Eine Handvoll Software-Entwickler setzen sich zusammen und organisieren eine Konferenz, die sie selbst gerne besuchen würden.

Diesen Satz habe ich auf der Webseite der Entwicklerkonferenz dotnet Cologne 2011 gefunden. Der sagt wohl eine Menge aus über das Konzept und die Absicht, eine Veranstaltung “von Entwicklern für Entwickler” zu konzipieren und umzusetzen. Und da das Ganze letztes Jahr schon ziemlich gut geklappt hat, kann man für die diesjährige Ausgabe der dotnet Cologne Ähnliches erwarten.

So wird es wohl nicht bei den 300 Teilnehmern vom letzen Jahr bleiben. Daher hat sich das Orga-Team rund um Albert Weinert, Stefan Lange und Roland Weigelt um eine neue Location umgesehen und wurde im Mediapark zu Köln fündig (es handelt sich dabei um das Komed). Und da auch einige neue Leute erwartet werden, gibt es diesmal auch 300- und 400-Level-Vorträge, die noch tiefer in diverse Themen einsteigen. Aber natürlich kommen auch fundierte Einführungen nicht zu kurz.

Toll ist auch die Idee, zwischen den einzelnen Sessions (von denen es immerhin 25 geben wird, aufgeteilt in fünf parallel laufende Tracks) etwas längere Pausen zu machen. Damit hat man auch mal die Gelegenheit, nach einem Vortrag mit den Referenten zu reden, einen der Sponsorenstände zu besuchen oder sich einfach einen Kaffee zu holen. Das reduziert den Stress und erhöht sicherlich die Zufriedenheit der Teilnehmer während der dotnet Cologne 2011.

Auf der zugehörigen Webseite gibt es auch schon erste Vorträge zu bewundern, und erfreulicherweise wird es auch etwas zu Windows Phone 7 geben (Peter Nowak erzählt etwas über Silverlight für mobile Geräte). Das hatte ich ja erst kürzlich hinsichtlich der .NET DevCon 2011 etwas bemängelt.

So, und worauf warten Sie jetzt noch, sich anzumelden? Hierbei ist vor allem Schnelligkeit oberstes Gebot, denn die ersten hundert Anmelder erhalten einen Rabatt von 30 Euro und bezahlen schlappe 25 Euro. Die nächsten 100 Konferenzwilligen werden aber auch noch belohnt und zahlen 15 Euro weniger, also 40 Euro. Alle anderen müssen leider den Standardpreis von 55 Euro zahlen. Aber auch das ist für eine Eintages-Konferenz für Software-Entwickler immer noch ein ziemlich gutes Angebot. Allerdings können Sie sich erst ab dem 14.3. um 14:00 Uhr anmelden.

Dass dieser sehr faire Eintrittspreis überhaupt möglich ist, hat auch mit den zahlreichen Sponsoren zu tun, die auch dieses Jahr die dotnet Cologne finanziell und sonstwie unterstützen. Zu ihnen gehört auch Intel, für die ich auf die dotnet Cologne fahren werde, um vor Ort über die wichtigsten Dinge zu berichten. Also schon mal vormerken: 6. Mai, Berichterstattung von der dotnet Cologne 2011 auf dem Software Dev Blog.

Zunächst einmal gilt festzuhalten, dass die Programmverantwortlichen acht Themenschwerpunkte definiert haben, vier am ersten Tag und vier am zweiten. Tag 1 umfasst die Rubriken “Sprachen”, “Architektur”,  ”SharePoint & Daten” sowie “ALM/Produktion”, an Tag 2 geht es um “Visual Studio & Add-Ins”, “Code & UI”, “Web-Ready Desktop” sowie “Soft Skills & Agile Methoden”. Zu meinen persönlichen Highlights zählen folgende Sessions:

• The absolutely minimum every developer should know about C# & Die Vielfalt der Programmiersprachen unter .NET (Rubrik Sprachen)
• Parallelprogrammierung – Eine Einführung & Die Task Parallel Library (Rubrik Architektur)
• SharePoint als Entwicklungsplattform & Alternative Datenbanken (Rubrik Sharepoint & Daten)
• Vertrauen ist gut – Source Control ist besser! & Buildserver, Continuous Integration und Continuous Deployment (ALM/Produktion)
• Mit ReSharper die Code-Qualität verbessern & Produktivitätssteigernde Visual Studio-Add-Ins (Visual Studio & Add-Ins)
• UI für Entwickler und andere Nicht-Designer & Code Design Guidelines in der Praxis (Code & UI)
• WPF, Silverlight, HTML 5 – die Qual der Wahl & HTML5: Der Browser als Plattform (Web-Ready Desktop)
• Was bringt mir Agil? & Agil 2.0 – Das Agile Development Framework (ADF) (Software Skills & Agile Methoden)

Was mir noch ein wenig fehlt, ist das Thema Windows Phone 7, da es auf eine ordentliche .NET-Veranstaltung durchaus passt (immerhin hat die dotnetpro WP7 schon einen kompletten Schwerpunkt spendiert). Außerdem kann ich keinen Slot für eine Keynote-Session entdecken. Das wäre wirklich schade, schließlich gibt solch eine Eröffnungsrede die Richtung für die gesamte Veranstaltung vor. Na, mal sehen, ob es sich die Verantwortlichen der .NET DevCon – Tilman Börner und Florian Bender – in dieser Sache noch einmal anders überlegen.

Falls Sie das Ganze auch ohne Keynote interessant finden, können Sie sich natürlich gleich mal anmelden. Wenn Sie das noch bis zum 19. April erledigen, sparen Sie 100 Euro und zahlen nur 690 Euro. Danach sind für zwei Tage .NET-Konferenz 790 Euro fällig. Hierin enthalten ist ein gemütliches Get-together am ersten Abend und ein separater Ausstellungsbereich, in dem diverse Firmen ihre Lösungen und Produkte in Sachen Software-Entwicklung präsentieren werden. Für das passende Socializing ist also auch gesorgt.

So, und was gibt es abschließend noch zu Olivers und Bernds Vorträgen zu sagen? Nun, beide waren (a) sehr unterhaltsam und (b) sehr informativ. Aber gut, das war ja auch nicht anders zu erwarten.

Oliver Sturm ist bestimmt vielen von euch ein Begriff: er ist unter anderem C#-MVP, betreibt ein eigenes Blog und twittert sogar ab und an. Seine Session trug den Titel “Parallelisierung mit funktionalen Ansätzen in C#”. Dabei ging es – grob gesagt – um den Multicore-Shift (“Wie übersetzt man das eigentlich?!”), um das Parallelisieren von Quellcode mithilfe der Parallel Extensions in .NET und um entsprechende funktionale Ansätze, demonstriert anhand zweier Beispiele (das Filtern von Namenslisten und die parallelisierte Erzeugung von Mandelbrotbäumen). Interessant fand ich übrigens Olivers Versuch, die Begriffe “Multithreading”, “Concurrency” und “Parallelism” voneinander abzugrenzen, da diese im englischen Sprachraum äußerst oft synonym verwendet werden. Tja, und den Rest seiner Präse schaut ihr euch am besten selbst an.

Bernd Marquardt beschäftigte sich dann mit einem ganz ähnlichen Thema, wenngleich aus einer anderen Richtung kommend: “Parallelprogrammierung mit der TPL”. TPL steht für Task Parallel Library, mit deren Hilfe das Parallelisieren von Managed Code vereinfacht werden soll. Natürlich zeigte auch Bernd zunächst einmal, dass die Prozessoren nicht mehr schneller werden, sondern “nur” noch mehr. Und dass Software-Entwickler aus diesem Grund eine ganze Menge Hirnschmalz auf die Optimierung ihrer Anwendungen verwenden müssen, damit diese auch optimal skalieren (die Anwendungen, nicht die Entwickler!).

Bernd stellte einstiegsweise die verschiedenen Parallelisierungsmodelle vor, über die Mario ja schon gut zwei Stunden vorher geredet hatte. Das erste praktische Beispiel war die parallele Erweiterung von LINQ, also PLINQ, die Microsoft seinem .NET-4-Framework spendiert hat. Damit lassen sich parallel ausführbare Datenbankabfragen generieren, die automatisch auf die vorhandenen Prozessorkerne und Threads verteilt werden. Aber auch das Parallelisieren von Schleifenkonstrukten mit neuen Funktionen wie Parallel.For() und Parallel.ForEach() waren Bernd ausführliche Erläuterungen wert.

Und so ging es dann lustig weiter: Codeblöcke parallelisieren mit Parallel.Invoke(), Task-Klassen einsetzen (vergleichbar mit der Threadpool-Klasse), Concurent Exceptions verwenden, Synchronisierungsprobleme erkennen und einiges mehr. Und wer das alles genauer wissen will, sollte sich einfach die Folien von Bernds Session auf seinen Rechner laden.

Dr. Mario Deilmann (so sein vollständiger Name) ist bei Intel für Compiler und ähnlich geartete Software-Tools zuständig. Mit seiner Lunch-Session ging er der Frage nach, welches Programmier- bzw. Thread-Modell für skalierende Anwendungen das beste sei. Skalierend bedeutet in diesem Zusammenhang, dass parallelisierter Quellcode nicht nur optimal auf zwei Prozessorkerne verteilt wird, sondern auch auf vier, sechs, acht oder 256 Kernen läuft – und zwar ohne Leistungseinbußen.

Hierfür ist laut Mario zunächst einmal ein passendes Profiling-Tool wie der Intel VTune Performance Analyzer erforderlich, mit dem man diejenigen Funktionen, Module und andere Stellen des Quellcodes aufspürt, die für die meiste Rechenleistung und -zeit verantwortlich sind. Denn das sind oft die Stellen, an denen man als Software-Entwickler ansetzen sollte. In vielen Fällen sind das zum Beispiel Schleifenkonstrukte, die sich bestens zum Parallelisieren eignen.

Eine der passenden Programmiermodelle wusste Mario natürlich gleich darzustellen: OpenMP. Allerdings weist diese pragma-basierte Parallelisierung von seriellen Anwendungen auch diverse Nachteile auf: Man denkt als Programmierer in Threads anstatt in Tasks (was laut Mario eigentlich ein absolutes No-Go sein sollte), es lassen sich keine eingebetteten Parallelkonstrukte realisieren und mit lokalen Daten geht OpenMP ebenfalls nur suboptimal um. Aber für die schnellen ersten Ergebnisse für parallel ausführbare Programme ist OpenMP laut Mario eine gute Wahl.

Außerdem unterstützt OpenMP keine objektorientierten Programmiersprachen wie C++, was natürlich in vielen Fällen ein klares KO-Kriterium ist. Aber wozu gibt es beispielsweise die Intel Threading Building Blocks. Mit dieser Thread-sicheren, hochoptimierten Sammlung von fertigen C++-Konstrukten lassen sich sequentiell programmierte Anwendungen recht schnell und ohne größere Kenntnisse der Parallelprogrammierung in parallel ablaufende Programme umwandeln. Praktisch an Intel TBB ist deren Vielseitigkeit: OS-seitig werden Linux, Mac OS und Windows unterstützt, und es gibt sogar eine nicht-kommerzielle Variante, die den LGPL-Lizenzrichtlinien unterliegt.

Neben OpenMP und Intel TBB existieren noch weitere Ansätze, wie sich Software parallelisieren lässt. Dazu gehört das noch recht junge Projekt Cilk++ von Intel, das einen ähnlichen Weg einschlägt wie Intel TBB, allerdings einen Parallel Debugger sein Eigen nennt, ein SDK bietet und auf hunderten von Prozessorkernen skalieren soll. Und vergessen sollte man natürlich auch nicht Parallel Studio, das unter anderem die Tools Parallel Inspector und Parallel Amplifier aufweist, mit deren Hilfe man Fehler im Quellcode aufspüren kann (Inspector) und sich die Anwendung weiter optimieren lässt (Amplifier). Das geht sogar so weit, dass Laufzeitfehler wie Race Conditions und Dead Locks aufgespürt werden können – bevor dies der Anwender später tut.

So, und die Sessions von Oliver Sturm und Bernd Marquardt sind dann morgen dran. Versprochen!

Da es auf diesem Blog ja um das Thema Multicore-Programmierung geht, widmet sich dieser Blogbeitrag der dotnet Cologne 2010. Zunächst einmal möchte ich den Organisatoren rund um Albert Weinert, Roland Weigelt und all den anderen ein großes Kompliment aussprechen: Ihr habt da wirklich ein tolles Event mit tollen Themen, Sessions und Sprechern organisiert. Ok, dass der Kaffee nicht immer warm war und die Technik gleich mal am Anfang nicht so recht wollte, übersehe ich gerne. Wichtig ist doch, dass die Inhalte stimmen und gut rübergebracht werden. Und das war auf jeden Fall so. Also zumindest kann ich das von den Vorträgen behaupten, die ich besucht habe.

Meine persönliche Sessionplanung umfasste vier Vortragende: Rami Radi und Mario Deilmann von Intel, den sehr unterhaltsamen Oliver Sturm und zu guter Letzt den werten Bernd Marquardt, der auf solch einer Veranstaltung natürlich nicht fehlen darf (und den ich im Juni auf den dotnetpro powerdays wieder erleben werde).

Ramis Session war wie immer sehr technisch orientiert und fand wegen der vielen Codebeispiele das Interesse der Zuhörenden, die sich im Raum “Bremen” eingefunden hatten. Und die wurden auch nicht enttäuscht: Rami legte sehr unterhaltsam dar, wie das Dreigestirn Windows 7, .NET 4 und Multicore-Architekturen voneinander profitieren. Dabei ging es unter anderem um ein wenig Grundlagenwissen in Sachen Nehahlem, also Turbo Boost, Quickpath-Architektur und andere Dinge.

Aber auch über die Verbesserungen von .NET 4 aus Multicore-Sicht wusste Rami anschaulich zu berichten: So stellte er Features wie Thread Scheduling, Thread Pooling, Garbabe Collection, TPL sowie PLINQ vor. Dabei gewährte er interessante Einblicke und verriet wichtige Details wie die parallele Aktualisierung von Gen-0- und Gen-2-Daten, die bei der Garbage Collection anfallen. Zudem ging er näher auf das Work-Stealing des in .NET 4 komplett überarbeitenden Thread Managers ein, bei der sich unterbeschäftigte Thread-Queues einfach Threads anderer Queues “klauen” können und so die Effizienz des Threadpool-Managers steigern.

Sehr erstaunlich fand ich auch die Tatsache, dass unter .NET 4 nun nicht mehr 25 Threads pro CPU verwaltet werden können, sondern derer 250! Hierfür ist allerdings ein sehr guter Scheduler notwendig, was Microsoft mit dem neuen .NET-Framework wohl gelungen ist.

Nach so viel Theorie wurde es dann sehr praktisch: Rami zeigte all die Verbesserungen unter .NET 4 im Hinblick auf seine Multicore-Fähigkeiten anhand eines Maze-Solvers, bei dem es um den den schnellsten Weg innerhalb eines Labyrinths von A nach B geht. Hierzu bediente er sich eines kleinen .NET-Programms, das er einmal unter .NET 3.5 und .NET 4 laufen ließ. Alleine schon der Umstieg von der älteren auf das brandneue Framework brachte beim Zeichnen des Labyrinths und dem anschließenden Finden des optimalen Wegs Zeitverbesserungen. Ganz zu Schweigen vom Unterschied zwischen dem seriell programmierten Programm und der Multicore-Variante mit mehreren Threads.

Abschließend startete Rami noch ein wenig den VTune Performance Analyzer, um der anwesenden Zuhörerschaft zu demonstrieren, wie sich mit dem Intel-Tool in .NET-Anwendungen solch hässliche Dinge wie Bottlenecks und False-Sharing-Probleme aufspüren lassen. Und wenn die Zeit nicht auf einmal vorbei gewesen wäre, hätte Rami wohl weitere zwei Stunden damit zugebracht, VTune in all seinen Facetten und mit all seinen Möglichkeiten vorzuführen.

Und was Mario, Oliver und Bernd in petto hatten, erfahrt ihr im zweiten Teil meiner dotnet-Cologne-2010-Berichterstattung.

In Köln bin ich, weil Intel dort einen Teil des Sponsorings übernommen hat und ich live aus dem Holiday Inn berichten werde, in dem die dotnet Cologne 2010 stattfindet. Das Programm habe ich ja schon in großen Teilen vorgestellt. Allerdings haben sich seitdem zwei Änderungen ergeben, die vor allem Intel betreffen. Und die will ich euch natürlich nicht vorenthalten.

Zum einen wird Mario Deilmann nicht über Intel Parallel Studio mit .NET und Visual Studio sprechen, sondern im Rahmen einer Lunch-Session die bekanntesten Windows-Modelle der Parallelprogrammierung vorstellen. Dabei geht es sicherlich um Multithreading-Konzepte wie OpenMP, APIs und Intel TBB. Und sicherlich wird auch Parallel Studio seinen Platz finden, alleine schon wegen der Unterstützung seitens Visual Studio 2010.

Zum anderen wird Kollege Rami Radi von Intel eine Stunde lang über Windows 7, .NET 4 und die Multicore-Programmierung sprechen. Wer sich hier schon länger tummelt, wird sich möglichweise daran erinnern, dass Rami diesen Vortrag schon mal gehalten hat. Womit er allerdings nicht minder aktuell wäre, denn das Thema Parallelprogrammierung hat mit Visual Studio 2010 und .NET 4 ja schließlich gerade erst begonnen.

Für alle, die der dotnet Cologne 2010 leider nicht beiwohnen können, folgt hier die gute Nachricht: Ich werde für euch von dort einen ganzen Tag lang über die wichtigsten und interessantesten Sessions in Sachen Parallelprogrammierung berichten. Macht euch schon mal einen dicken, roten Kringel um den 28. Mai 2010!

• Funktionale Programmierung in C# 3.0 (Oliver Sturm)
• Anpassbare Anwendungen mit Windows Workflow 4 (Dariusz Paris von Microsoft)
• Intel Parallel Studio mit .NET und Visual Studio (Mario Deilmann von Intel)
• Debugging in Deep mit VS2010 und WinDbg (Gregor Biswanger)
• Parallelprogrammierung mit der TPL (Bernd Marquardt)
• und viele andere

Das ist nur das vorläufige Programm. Der ganze Tag besteht aus vier parallelen Teilen, in denen insgesamt 24 Vorträge plus Auftaktrede und fünf Lunch-Sessions stattfinden sollen. Da könnt ihr euch auf einiges gefasst machen.

Und damit der Tag nicht nur aus Arbeit besteht, beginnt um etwa halb sieben der unterhaltsame Teil der Dotnet Cologne mit Verlosung und anschließender Grillparty (hoffentlich passt das Wetter). Müst ihr da nicht dabei sein? Doch, ich finde schon. Ihr solltet euch allerdings beeilen, denn so richtig viele Plätze gibt es nicht mehr (es ist von etwa 50 die Rede). Also, wir sehen uns, oder?!

Sein Titel (also der des Buches): “Parallel Computing in .NET”. Sein Autor: Marc André Zhou. Sein Umfang: rund 360 Seiten. Seine ISBN: 978-3-86802-038-0. Seine Mission: Wie mache ich dotNET-Entwicklern klar, dass sie von der sequentiellen Programmierung umsteigen sollten auf die parallele. So gesehen finde ich den Titel ein wenig unglücklich gewählt, wenngleich es in dem Buch natürlich auch um Parallel Computing geht. Doch zuvorderst sollen die Leser dieses gedruckten Leitfadens etwas über Multithreaden und Co. lernen.

Und hierfür hat der Autor wirklich sehr viel an Informationen zusammengetragen. Das beginnt mit einer kleinen Aufklärungsrunde in Sachen Parallel Computing (sic!), die sogar die parallelen Programmiermodelle betrachtet. Anschließend wird es ein wenig theoretisch, indem Zhou so Dinge wie das Amdahlsche und das Gustafson-Gesetz betrachtet. Das hilft auf jeden Fall für ein grundsätzliches Verständnis, wann die Parallelprogrammierung sinnvoll ist – und wann nicht.

Nach weiteren allgemeinen Informationen rund um die Regeln des Parallel Computing, aber auch des Projektmanagement und den Modellierungsmöglichkeiten geht es dann nahtlos über in das Basiswissen rund um Threads unter .NET. Dies ist jedoch schon wieder fast veraltet, denn mit der Einführung von .NET 4.0 wird kein Mensch mehr von .NET-Threads und deren manuellem Erstellen reden.

Dies weiß aber auch der Autor, und so betrachtet er natürlich auch die kommenden Techniken und Tools wie die CLR-Threadpools, die Task Parallel Library, PLINQ,  Parallel Computing/Programming mithilfe von Visual Studio 2010 und die Concurrency and Coordination Runtime im Detail. Und den Abschluss des Buches bildet eine genauere Betrachtung möglicher zukünftiger Programmiermodelle: Axum und Software Transaction Memory.

Fazit: “Parallel Computing in .NET” ist sicherlich eine gute Quelle für alle, die mehr wissen wollen zum Thema Parallelprogrammierung mithilfe des .NET-Frameworks. Es zeigt anschaulich und sehr detailliert, wohin die Reise gehen wird und was künftige Parallelprogrammierer erwartet, vor allem mit .NET 4.0. Anhand geeigneter Codebeispiele werden wohl selbst unerfahrene Multithread-Entwickler einen Zugang zu diesem nicht ganz trivialen Thema finden. Und für alle, die mehr wissen wollen zu diesem Buch, gibt es auf der zugehörigen Webseite die passenden Infos.

Surftipp: Falls ihr euch für die Quellcodebeispiele des Buches interessiert, solltet ihr mal auf diesen Link klicken.

Daher hat’s mich sehr gefreut, dass ich heute Morgen zwei “neue” Screencasts” auf Channel 9 gefunden habe. Das erste beschäftigte sich mit der Frage, wie sich die Klasse Parallel dazu nutzen lässt, mehrere Funktionsblöcke gleichzeitig auf mehreren Prozessorkernen ablaufen zu lassen. Hierzu stellt die Parallel-Klasse ein Methode zur Verfügung, die sich Invoke nennt.

Praktisch an dieser Form der Parallelisierung ist die Tatsache, das die gleichzeitig ablaufenden Funktionen nicht synchronisiert werden müssen. Der Mainthread wird nämlich erst dann fortgesetzt, wenn die parallelen Threads fertig sind. Darum kümmert sich die Concurrency Runtime.

Screencast Nummer 2 zeigt in nur sechs Minuten, wie sich Tasks definieren lassen, die einen Rückgabewert liefern. Auch das hat den großen Vorteil, dass der Mainthread nicht unnötig warten muss, bis ein oder mehrere parallel ablaufende Aufgaben fertig sind. Die Übergabe des Returnwertes sorgt nämlich für die Synchronisation des Programmablaufs. Schön daran ist zudem, dass sich auf diesem Weg mehrere Tasks verknüpfen lassen und so ein Folgetask mit dem Rückgabewert des Vorgängertasks “gefüttert” werden kann. Es lassen sich aber nicht nur einfache Werte, sondern auch Objekte übergeben.

Mittwoch ging es dann wieder nach München, damit ich am Donnerstag auch ja pünktlich auf der .NET-Multicore-Konferenz sein konnte, um von dort aus live zu bloggen. Was auch gut geklappt und zudem viel Spaß gemacht hat. Und es war nicht nur informativ, sondern auch sehr unterhaltsam, Ralf Westphal und Bernd Marquardt gemeinsam auf der Bühne zu erleben. Denn neben der geballten fachlichen Kompetenz konnten die zwei auch mit Entertainment-Qualitäten überzeugen. Stellenweise habe ich mich an meine Jugend erinnert gefühlt, in der Statler und Waldorf auf dem Muppet-Show-Balkon Ähnliches abgeliefert haben.

Neben all der Unterhaltung stand natürlich das Fachliche im Vordergrund, und das war sehr fundiert. Es ging um wirklich spannende Dinge:

• Zunächst durfte Rami Radi von Intel die Konferenz mit seiner Keynote eröffnen. Sein Vortrag war (a) sehr folienlastig und (b) sehr informativ, wenngleich er dem ein oder anderen Zuhörer eine ganze Menge abverlangt hat. Mit Basics oder ähnlichem Ballast hat sich Rami erst gar nicht aufgehalten, sondern ging gleich in Medias Res. Wie gesagt: tough stuff!

• Was dann kam, hätte ganz gut vor Ramis Grundsatzrede gepasst: Eine Einführung in das Thema Multicore-/Multithread-Programmierung. Dort gingen Ralf und Bernd richtig interaktiv auf wichtige Fragen rund um die parallele Programmierung ein. Dazu gehören Latenzprobleme, der gemeinsame Zugriff auf Speicherressourcen, das Gesetz von Amdahl und der Umgang mit Threads.

• Teil drei der Multicore-Konferenz brachte dann Statler und Waldorf, äh, Ralf und Bernd erneut gemeinsam auf die Bühne, damit sie über Multithreading mit .NET-Bordmitteln reden konnten (genauer: mit Bordmitteln des .NET-Frameworks). Dabei ging es um wichtige Aspekte wie die Steuerung von Threads, den .NET-Threadpool, asynchrone Methoden und atomare Anweisungen.

• Nach der Mittagspause mussten dann Ralf und Bernd ohne ihre Alter Egos erneut “vors Mikro”, um über die parallele Programmierung unter .NET 3.5 einerseits und die Microsoft Concurrency Coordination Runtime anderseits zu referieren. Bernd erzählte unter anderem von der Schleifenparallelisierung, parallelen Aggregationen, von Task- und Future-Klassen und hatte sogar ein paar Tipps und Tricks dabei. Ralf seinerseits ging verstärkt auf das Thema Synchronisierung und das Warteschlangenprinzip der CCR ein.

Die CCR ermöglicht ein neues Programmiermodell für parallel laufende Anwendungen. Ein sehr schöner Ausspruch von Ralf lautet übrigens: “Vergesst Threads!”, da Threads synchronisiert werden müssen, was Ralf nicht wirklich mag. Um das besser verdeutlichen zu können, schreibt er in Echtzeit verschiedene kleinere Programme. Sehr schlau!

Das Besondere an der CCR ist das Warteschlangenprinzip: Jeder Befehl oder jedes Datum wird im Hintergrund aus der Warteschlange ausgelesen und verarbeitet, sobald eine Ressource frei ist. Damit müssen keine expliziten Threads erzeugt und wieder beendet werden, da sich die CCR automatisch darum kümmert. Hierfür steht die DispatcherQueue-Klasse zur Verfügung.

Die CCR erlaubt sowohl den Einsatz des Standard-Threadpools als auch eigene Threadpools auf Dispatcher-Basis.

Folgende Elemente kommen zum Einsatz:

• Parallele Erweiterungen für LINQ = PLINQ

• Schleifen parallelisieren: Die hierzu gehörige Klasse heißt System.Threading.Parallel. Schleifen werden auf mehrere Threads aufgeteilt werden, aber nur, wenn die einzelnen Schleifendurchläufe unabhängig voneinander sind. Dabei müssem die Indezies alle gleich sein. Am Ende der Schleife werden alle Threads synchronisiert. Fazit: Schleifenparallelisierung lohnt sich nur bei komplexen und großen Schleifen! Wichtig ist auch die richtige Verteilung einer Schleife auf die vorhandenen Prozessorressourcen. Dies gelingt, indem die einzelnen Schleifendurchläufe in kleinen Portionen verarbeitet werden.

• Aggregationen: Hierbei geht es um das Zusammenfassen von Ergebnissen. Dabei ist Locking meist erforderlich. Zwischenwerte werden über sogenannte ThreadLocateState weitergegeben. Der Ablauf sieht folgendes vor: Initialisierung, Zwischenspeichern der einzelnen Thread-Ergenisse und das abschließende Zusammenführen der Zwischenwerte inklusive Locking. Übrigens: Aufgrund des Zusammeführens der einzelnen Thread-Zwischenergebnisse kann ist bei der parallelen Ausführung zu Rundungsfehlern kommen und das Ergebnis weicht vom sequentiellen Programm ab.

• Codeblöcke parallelisieren: Hier kommt die Invoke-Methode zum Einsatz.

• Die Task-Klasse: Diese funktioniert ähnlich wie die ThreadPool-Klasse und haben dieser gegenüber wesentliche Vorteile: Sie lassen sich mit wait() synchronisieren und abbrechen. Interessant an dieser Task-Klasse ist die Tatsache, dass dahinter ein spezieller Thread-Pool steckt, der deutlich schneller als der Standard-Threadpool arbeitet.

• Die Future-Klasse: Sie ist abgeleitet von der Task-Klasse und ermöglicht die asynchrone Berechnung von Daten. Dabei wird auf Daten, die noch berechnet werden, automatisch gewartet oder das Endergebnis sofort ausgegeben. Die Future-Klasse eignet sich übrigens dazu, die Bedienoberfläche von Hintergrundberechnungen zu entkoppeln und damit die Anwendungen performanter zu machen.

• Concurrent Exceptions: Im Gegensatz zu sequentiellen Anwendungen können in parallelisierten Applikationen zu einer bestimmten Zeit mehrere Exceptions ausgeworfen werden. Hierfür ist natürlich ein anderer Exception-Mechanismus erforderlich. So müssen zum Beispiel im Falle einer Exception mehrere Threads gleichzeitig angehalten werden.

• Synchronisierung: Hierfür sind diverse Klassen im .NET-Framework vorhanden wie Lazyinit und WriteOnce.

Tipps und Tricks:

• Bei Parallel.For und Parallel.ForEach muss die (Anzahl der Durchläufe * Dauer) auf jeden Fall groß genug sein (beispielsweise schlägt bei der Matrix-Multiplikation die Parallelisierung erst bei sehr großen Matrizen voll durch).
• Nur äußere Schleifen parallelisieren wegen der Abhängigkeiten der Variablen
• Amdahl’s Gesetz berücksichtigen

• Statisches Threading birgt vor allem ein Problem: Es gibt statische Variablen, die von mehreren Threads gleichzeitig schreibend genutzt werden können.

• Threading mit instanzierten Klassen: Jeder Thread hat seine eigene Instanz, also zum Beispiel seine eigenen Variablen, was natürlich ein wenig mehr Ressourcen kostet.

• Steuerung von Threads: Hierbei geht es um die Priorisierung von Threads sowie das Starten, Pausieren und Stoppen von Threads. Die Herausforderung ist hier der jeweils richtige Zeitpunkt, ein Thread zu manipulieren. Außerdem muss man feststellen können, ob ein Thread gewollte beendet wurde. Dies kann per Bool’scher Variable erreicht werden.

• .NET-Threadpool: Der Pool soll ein einfaches Arbeiten mit mehreren Threads ermöglichen. Diese Threads “leben” meist relativ lang oder werden regelmäßig wiederkehrend benötigt. Es gibt eine maximale Anzahl an Threads innerhalb eines Pools. Wir ein Pool-Thread 30 Sekunden nicht benötigt, wird der Thread aus dem Pool entfernt. Schwierig dabei kann auch sein, dass ein neuer Pool-Thread erst nach einer halben Sekunde erzeugt wird, wenn kein laufender Thread in dieser Zeit beendet wird. Und: Jeder Prozess hat seinen eigenen Thread-Pool.

• Asynchrone Methoden: Einzelne Aufgaben werden in eigenen Threads ausgeführt. Die hierzu benötigten Methoden heißen BeginInvoke und EndInvoke. Allerdings sind diese Methoden kaum sinnvoll anwendbar.

• BackgroundWorker: Besteht aus drei Klassen: DoWork, ProgressChanged und ReportProgress.

• Synchronisierung: Im .NET-Framework gibt es Klassen für die Synchronisierung von Objekten.

• Atomare Anweisungen: Viele Befehle dürfen nicht unterbrochen werden. Daher stellt die Interlocked-Klasse sicher, das Grundbefehle vollständig ausgeführt werden, wenn mehrere Threads auf die Variablen zugreifen können: Increment/Decrement, Exchange, CompareExchange, Read (new), Add (new). Dies ist zum Beispiel für Sortieralgorithmen wichtig.

Zunächst geht es um echte Basics wie Multithreading mit Single- und Multicores. Fakt ist: Multithreading allein bringt gar nichts, dafür sind mehrere Prozessoren und die Zerlegung eines Programms in parallel zu verarbeitenden Bereiche notwendig.

Eine weitere Herausforderung sind Latenzzeiten, die sich aus asynchroner Prozessorverarbeitung ergeben. Das lässt sich mithilfe einer Kombination aus Multithreading und Multitasking auf mehreren Prozessoren optimieren.

Es gilt aber zugleich, den Durchsatz zu erhöhen. Dies gelingt ausschließlich auf Multicore-Systemen.

Es gibt ein grundsätzliches Problem bei der Parallelverarbeitung: den Zugriff auf gemeinsame Ressourcen. Diese Herausforderung meistern Zugriffskontrollen mithilfe explizierter Sperren. Hierfür sperren zum Beispiel einzelne Tasks gemeinsamen Speicher. Allerdings müssen die Zeitspannen und die Granularität dieser Sperren genau passen. Ein große Gefahr hierbei sind übrigens mögliche Deadlocks, die gerade bei parallel programmierten Anwendungen erst zur Laufzeit auftreten. Deadlocks lassen sich durch dieselbe Sperrreihenfolge vermeiden.

Jetzt redet Bernd über Data Races, die immer dann entstehen, wenn mehrere Threads auf dieselbe Ressource wie eine Variable schreibend zugreifen. Und das ist leider nicht vorhersehbar, da der schnellere Thread meist “gewinnt”.

Abschließend geht Bernd noch auf das Gesetz von Amdahl ein. Das hat mit dem Aspekt zu tun, dass die meisten Anwendungen nicht vollständig parallelisiert werden können bzw. sollen. Daher ist die Temposteigerung von seriellen Programmen, die parallelisiert werden, meist nicht optimal. Und das bedeutet laut Amdahl, dass der sequenzielle Teil einer Anwendung maßgeblich für die Temposteigerung zuständig ist.

Eine weitere Einschränkung bei der Geschwindigkeitssteigerung sind limitierende Faktoren wie das Erzeugen und Zerstören von Threads, Cache-Synchronisierungen und so fort. Die Erzeugung eines Threads dauert zum Beispiel so lang wie die Addition von 1.000 Integer-Zahlen. Abhilfe schaffen Threadpools, mit deren Hilfe ein Thread einmal erzeugt wird und dann immer wieder zur Verfügung steht. Wichtig ist aber auch die Granularität der Threads, damit die vorhandenen Ressourcen optimal genutzt werden.

Fazit: Es gibt je nach Rechendauer und -aufwand einen optimalen Parallelisierungsgrad. Und Threadpools helfen, parallelisierte Anwendungen zu beschleunigen.

Den Anfang macht Rami Radi von Intel, der die Einführungsrede hält und die Anwesenden auf das Thema Multicore einstimmen will.

Rami beginnt seinen Vortrag mit Hardware, nicht mehr Software. Namentlich spricht er über den Core i7-Prozessor, der ja im höchsten Maße multithreading-tauglich ist. Core i7 verarbeitet nämlich pro Prozessorkern zwei Threads simultan.

Die nächste Folie zeigt die ganze Vielfalt der Intel-Entwicklertools, über die ich hier schon ausführlich berichtet habe, also über Compiler, VTune etc.

So, jetzt wird’s ernst. Rami spricht über die Parallelprogrammierung im .NET-Umfeld, was seiner Meinung nach nicht einfach ist (wären wir sonst hier?). Zu den Herausforderungen gehören unter anderem falsch genutzter Speicher, zu viele und zu wenige Threads, gemeinsam genutzte Speicherbereiche, Load Balancing und viele andere. Wie gut, dass es für diese “Issues” die passenden Tools gibt wie den VTune Performance Analyzer.

Aber es gibt laut Rami auch genug Fälle, in denen parallelisierte Anwendungen langsamer laufen als serielle. Das hat diverse Gründe: Der serielle Code nimmt immer noch zu viel Raum ein, die kritischen Pfade sind nicht vernünftig parallelisiert oder die Speicherbandbreite reicht nicht aus.

Die nächste Folie zum Thema .NET-Konstrukte wirkt auf den ersten Blick ein wenig überfrachtet. Zum Glück will sich Rami auf die wirklich wichtigen Aspekte konzentrieren. Dazu gehören Thread-Pools. Rami zeigt ein kleines Beispiel anhand einer kleinen Fotoverwaltung, die in C# geschrieben ist.

Der Vorteil von Thread-Pools ist in diesem Fall, dass nicht ein, sondern zwei oder mehr Bilder gleichzeitig aus der SQL-Datenbank ausgelesen werden können, die die Bilder aufbewahrt. Der Trick hierbei ist übrigens, die Thread-Parameter in die For-Schleife zu packen. Außerdem muss ein Wait-Signal eingebaut werden, damit die Anwendung am Ende weiß, dass alle Bilder angezeigt worden sind. Darüber hinaus ist ein Lock-Befehl einzufügen, der die SQL-Zugriffe synchronisiert.

Interessant: Innerhalb des .NET-Umfelds kann nativer Code eingesetzt werden, um leistungsfähige Bibliotheken zu nutzen.

Jetzt gibt’s noch ein paar nützliche Tipps, mit denen man multithread-optimierten Code noch besser machen kann. Dazu gehören das Auslesen der vorhandenen Prozessorressourcen, das Zusammenfassen mehrerer Funktionen zu einem einzigen Thread, das Cachen von häufig benutzen Daten und das Benutzen von parallelen Datenbankverbindungen.

Schließlich gibt es noch eine kleine Einführung in VTune, mit dem sich Anwendungen prima analysieren lassen.

Im Gegensatz zum letzten Blogeintrag steht mittlerweile fest, wer die Keynote-Rede halten wird. Es ist Rami Radi, Senior Software Application Engineer bei der Software und Services Group von Intel. Rami wird unter anderem den Irrglauben vieler .NET-Entwickler zerschlagen, dass ihre Anwendungen automatisch mit den aktuellen Hardware-Plattformen skalieren. Daher wird Rami zeigen, welche Schritte notwendig sind, um .NET-Software für Multicore-Plattformen wie den Core i7 von Intel zu analysieren, zu optimieren und fein abzustimmen.

Anschließend werden Bernd Marquardt und Ralf Westphal gemeinsam einen ersten Einblick in die Welt der Parallelverarbeitung und -programmierung gewähren. Das Auditorium wird also eine Menge über die Terminologie der Multicore-Programmierung erfahren. Zudem stehen die Konzepte des Multithreadings sowie deren Herausforderungen auf Bernds und Ralfs Agenda.

Nach einer kurzen Kaffeepause geht es dann ans Eingemachte: “Parallelverarbeitung mit .NET Bordmitteln”. Was bietet das .NET-Framework, um die eigenen Softwareprojekte für Core i7 und Co. zu optimieren. Ein kleiner Tipp: Hierzu gibt es auf diesem Blog eine ganze Menge nachzulesen. Wer die Infos dazu findet, darf sie behalten!

Am Nachmittag finden dann drei weitere Vorträge statt: “Parallele Algorithmen: Die Parallel Fx Library”, “Parallele Architekturen: Die Concurrency Coordination Runtime” und “Chances for parallel programming with the functional programming language F#”. Speziell die letzte Präsentation, die von F#-Guru Don Syme gehalten wird, birgt ein hohes Informationspotenzial. Denn es geht bei F# um einen ganz neuen Denkansatz für die parallele Programmierung, der auch dringend notwendig sein wird. Spätestens dann, wenn Visual Studio 2010 mit all seinen parallelen Möglichkeiten auf den Markt kommen wird – inklusive F#.

Ach ja: Um dem Thema F# und der funktionalen Programmierung einen gebührenden Rahmen zu geben, gibt es eine Warm-up-Veranstaltung zu diesem Thema. Don Syme, Bernd Marquardt und Ralf Westphal werden sich zwischen 17.30 und 21.30 Uhr drei volle Stunden Zeit nehmen, um mit euch über F# und die Parallelprogrammierung im .NET-Framework zu diskutieren.

Frühbucherrabatt-Tipp: Wer sich jetzt noch ganz schnell anmeldet (und zwar bis zum nächsten Montag, den 23.3.) kann satte 100 Euro für die Teilnahme am prio.powerday sparen (390 Euro statt 490 Euro). Das gilt natürlich auch für die Kombination aus F#-Nighttalk und .NET-Multicore-Konferenz. Also, worauf wartet ihr noch?!

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.

Wie unterstützt das .NET Framework 4.0 die parallele Programmierung?
Hierfür gibt es diverse Komponenten. Es wird sowohl für den Bereich “Managed Applications” – also C# und Konsorten – als auch für native Programmiersprachen (Fortran, C++ etc.) Bibliotheken und ähnliche Dinge geben. Für beide Programmiermodelle wurde die Concurrency Runtime entsprechend aufgebohrt.

Für die .NET-Entwickler gibt es dann zwei neue Modelle, und zwar die Task Parallel Library (TPL) und PLING. Mit der TPL lassen sich Aufgaben abstrahieren, was unter der Oberfläche und mithilfe der Concurrency Runtime zu Threads führt, um deren Verteilung auf die einzelnen Prozessorkerne sich der Entwickler nicht mehr kümmern muss. PLINQ stellt eine parallelisierte Erweiterung von LINQ dar. Und LINQ wiederum ist “eine Komponente von Microsofts .NET-Framework, mit der SQL-, XLink- und XQuery-Anfragen direkt in .NET-Programmiersprachen wie C# 3.0 oder VB.Net 9.0 als Code statt als String eingebunden werden können” (Quelle: Wikipedia).

Aber auch bei den nativen Sprachen gibt es neue Ansätze bezüglich der Concurrency Runtime: Dies ist zum einen die Parallel Pattern Library, die sich mit den Intel Threading Building Blocks vergleichen lässt. Zum anderen bietet Visual Studio 2010 eine Agent Library für C++ und Co, die bestimmte Aufgaben verwalten und ausführen kann.

Was sagen Sie Entwicklern, wenn Sie mit ihnen über die parallele Programmierung reden?
Das hängt davon ab, mit wem ich spreche. Entwickler, die sich zum Beispiel schon länger mit serviceorientierten Anwendungen beschäftigen, in denen separate Aufgaben durch Dienste erledigt werden, verstehen das Konzept der parallelen Programmierung oft schneller als Programmierer, die nur die rein serielle Entwicklung kennen. Wichtig dabei ist die Erkenntnis, dass es in den meisten Anwendungen Programmteile gibt, die man loslösen kann von der restlichen Programmlogik. Ein Beispiel hierfür ist die parallele Speicherung von Daten.

Für viele Entwickler stellt aber die Parallelisierung von Bedieneroberflächen ein großes Problem dar, da hier vieles noch vom Betriebssystem mithilfe von Nachrichtenschlangen verwaltet wird. Hierfür wird es in .NET 4.0 entsprechende Bibliotheken geben, die diese Aufgaben automatisch übernehmen.

Welche Anwendungsgruppen werden von der Parallelisierung hauptsächlich profitieren?
Da sind zum einen die algorithmus-basierten Anwendungen zu nennen (Bildbearbeitung, Encoder etc.), aber auch klassische Geschäftsanwendungen wie CRM-Systeme bergen viel paralleles Potenzial. Hier können beispielsweise Anfragen an das Backend simultan ausgeführt werden, was die Wartezeiten auf das Ergebnis verkürzt. Allerdings liegt allen parallelisierten Anwendungen eine bestimmte Arbeit vor dem eigentlichen Kodieren zugrunde: Welche Programmbereiche kann ich logisch zusammenfassen und daraus einzelne Aufgaben machen, die als Tasks abstrahiert werden können und sich dann von der Concurrency Runtime als separate Threads ausführen lassen.

Wie unterstützt Microsoft die Community in Sachen Visual Studio 2010, .NET 4.0 und Parallelprogrammierung?
Neben den kommerziellen Konferenzen wie der Microsoft Tech-Ed oder dem Tech Summit gibt es beispielsweise die Möglichkeit, über Microsoft in ein Early-Adopter-Programm hineinzukommen, um auf diesem Weg Betatester zu werden. Darüber hinaus kann man uns auch direkt auf gewünschte Workshops und ähnliche Dinge ansprechen. Und natürlich nutzen wir die gesamte Online-Vielfalt wie Webcasts und Blogs, um unsere Themen zu kommunizieren. Aber auch viele Microsoft-nahe Communities stehen derlei Themen offen gegenüber. Dort trägt Microsoft an und ab selbst zur Aufklärung in Sachen Multicore und ähnlichen Dingen bei.

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.

Aus diesem Grund werde ich mich heute und morgen Nachmittag im Messezentrum München herumtreiben und diesbezügliche Informationen zusammentragen. So treffe ich unter anderem die Leute der Dotnetpro, die auf der OOP mit einem eigenem Stand vertreten sein werden. Eines ihrer Themen wird die erste deutschsprachige Multicore-Konferenz sein, die am 23. April diesen Jahres ebenfalls in München stattfindet.

Am Dotnetpro-Stand hoffe ich die Hauptredner des Multicore-Powerday zu treffen, Ralf Westphal und Bernd Marquardt. Mit beiden plane ich kurze Interviews, in denen sie mir hoffentlich ein wenig mehr über ihre Sessions auf der Eintagesveranstaltung im April erzählen werden.

Nach diesen Interviews treffe ich mich mit einer weiteren Koryphäe der Multicore-Programmierung: Walter F. Tichy von der Uni Karlsruhe, der um 17:45 Uhr mit seinem Vortrag “Herausforderung Mehrkernsysteme” dran ist. Im Gespräch mit ihm werde ich versuchen, die scheinbaren Widersprüche aufzulösen, die in seinem Gastbeitrag zu stecken scheinen, den er für die Online-Ausgabe der Computerzeitung geschrieben hat. In seinem Vortrag scheint er ebenfalls ein, zwei diskussionswürdige Thesen zu vertreten:

Der Vortrag skizziert die gegenwärtige Hardwareentwicklung und geht dann auf erste Erfahrungen mit der Parallelisierung nicht-numerischer Anwendungen ein. Insbesondere werden einige der üblichen Parallelisierungsempfehlungen als Mythen entlarvt.

Wie dem auch sei, ich bin schon sehr gespannt, was die Herren Westphal, Marquardt und Tichy zu erzählen haben. Und was sonst noch alles auf der OOP 2009 los ist, sehe ich mir ebenfalls an und werde darüber live und in Farbe berichten. So, stay tuned …

Update: Ich habe während der OOP 2009 zwei Vorträge zum Thema Multicore-Programmierung besucht. Daraus sind 12 Thesen zur Multithread-Entwicklung enstanden sowie eine mehrteilige Mini-Serie zum Thema Multicore-Programmierung (Teil 1, Teil 2, Teil 3).

Da wäre zum einen der Schauplatz zu nennen: Das Konferenzzentrum befindet sich in unmittelbarer Nähe der FH München, also dort, wo unter anderem die Software-Entwickler von morgen ausgebildet werden. Ich habe auf jeden Fall gerade eine Mail an eine meiner Ex-Professorinnen abgeschickt; vielleicht wird ja dort an der Hochschule für angewandte Wissenschaften auch das Thema Multicore gelehrt (nix mehr FH!).

Zum anderen geht es auf der Webseite natürlich auch um die Inhalte der Konferenz, die zum Großteil schon feststehen. Diese ranken sich wie bereits berichtet um folgende Themen:

Um 9 Uhr findet zunächst einmal die Keynote-Präsentation statt. Wer diese halten wird, ist noch offen. Zumindest findet sich in der Agenda noch kein Name.

Ab 9:45 Uhr gibt es eine Einführung in das Thema Parallelverarbeitung. Es geht um Deadlocks, Race Conditions, Latenzen, Kanäle und andere Dinge.

Nach der Kaffeepause geht es ab 11.15 Uhr einen Schritt weiter: Bernd Marquardt und  Ralf Westphal erläutern, wie man mit .NET-Bordmitteln parallel programmierte Anwendungen erstellt. Sie behandeln also Begriffe wie ThreadPool, BackgroundWorker, WaitHandle und mehr. Grundwissen für Programmierer.

Nach dem Mittagessen (14:00) wird es dann ernst: Bernd zeigt den Anwesenden, wie sich die .NET-Bordmittel um höhere Abstraktionen erweitern lassen: Er spricht über Parallel Fx, PLinq und die Task Parallel Library (TPL), die Parallelprogrammierern bei ihrer Arbeit helfen sollen.

Ab 15:15 Uhr ist Zeit für den Blick aufs “Große Ganze”, sprich auf das Synchronisieren einzelner Aufgaben und Funktionen zu einem skalierenden Quellcode. Außerdem geht es um die Parallelität auf Architekturebene, wofür Microsoft die Concurrency Coordination Runtime (CCR) entwickelt hat.

Um 16:45 Uhr wird das große Finale eingeläutet: Bernd und Ralf stellen die funktionale Programmiersprache F# aus dem Hause Microsoft vor, mit der vor allem Synchronisierungsprobleme einfacher handhabbar sein sollen. F# bietet aber auch ganz neue Ansätze der Parallelprogrammierung. Nicht umsonst steckt Microsoft eine Menge an Arbeit und Geld in F# (und nicht zu vergessen die Anstrengungen rund um Visual Studio 2010).

Ach ja: Für die Multicore-Konferenz kann man sich ab sofort anmelden. Die Tageskarte kostet regulär 490 Euro, bis zum 23. März 2009 allerdings nur 390 Euro. Um diese 100 Euro Rabatt einstreichen zu können, müsst ihr bei der Anmeldung den Rabattcode PPMC9SDB eingeben.

Und dieser “Krafttag” wird es wohl in sich haben. Es geht unter anderem um folgende Fragen:

• Wie nutze ich aktuelle und zukünftige Multicore-Prozessoren optimal für meine Anwendungen?

• Welche Konzepte und Werkzeuge der Parallelprogrammierung gibt es?

• Was ist die Concurrency Coordination Runtime und welche Aufgaben übernimmt sie?

• Welche Bedeutung haben die Parallel Extensions für das .NET-Framework und wie setze ich sie am besten ein?

• Wie erstelle mithilfe von F# parallel programmierte Anwendungen?

Diese und viele weitere Fragen werden auf der großen .NET-Konferenz beantwortet. Und zwar von bekannten Größen der Branche wie Ralf Westphal und Bernd Marquardt, beide ihres Zeichens Microsoft MVP.

Falls Sie also zu den .NET-Entwicklern gehören, die unbedingt mehr wissen wollen (oder müssen) zum Thema Multicore-Programmierung, sollten Sie den 23. April schon mal ganz fett und dick im Kalender markieren.

Spartipp: Geben Sie bei der Anmeldung zum Multicore-Powerday einfach den Gutscheincode PPMC9SDB ein und schon sparen Sie 100 Euro. Ist das nix?!

Update: Sodala, jetzt ist auch die zugehörige Webseite online.