Gestern auf der SET 2009 in Zürich habe ich einen Vortrag über die Concurrency Coordination Runtime (CCR) von Microsoft gehalten. Leider standen mit nur 45min zur Verfügung :-( Dennoch glaube ich, dass die Botschaft, die Zukunft liege bei asynchronen Komponenten, um Multicore Prozessoren auszureizen, bei den Teilnehmern angekommen ist. Der Raum war jedenfalls voll und alle schienen am Ende zufrieden. Vielleicht waren sie aber auch nur noch benommen vom Codefeuerwerk, dass ich abgebrannt habe? ;-) Denn ich habe neben 1-2 Flipchartblättern nur Code mit CCR-Beispielen gezeigt. Den gibts hier auch zum Download. Da asynchrone Programmierung für viele neu ist, mögen die Konstrukte auf die Schnelle nicht immer einfach zu verstehen gewesen sein, auch wenn ich mich auf die CCR-Grundlagen beschränkt habe. In jedem Fall freue ich mich, dass am Ende noch 10 Minuten "Überziehungszeit" war, um auch noch die transparente Verteilung von CCR-basierten asynchronen Komponenten demonstrieren. Denn: Wer schon lokal asynchron programmiert, hat es viel einfacher, skalierbare verteilte Architekturen aufzusetzen.
6 Kommentare:
"Codefeuerwerk" hin oder her, aber bei diesem Thema wären ein paar Folien mit dem architektonischen Grundgedanken der CCR sicherlich besser gewesen. Mir ging es zumindest bei dem prio.powerday so. Live coding ist ja nett, aber gerade bei diesem Thema sollte dies von ein paar Architektur Folien begleitet werden. Haben Sie nicht auch einmal in der dotnetpro geschrieben, dass Sie bei Beratungsterminen in Firmen nie sofort den Code sehen wollen da dadurch der Blick auf das Wesentliche verloren geht.
@teichgraf: Ja, ich hätte Folien machen können. Bewusst habe ich darauf verzichtet zugunsten von Code angesichts der Kürze der Zeit. Ich wollte gerade keinen konzeptionellen Vortrag machen, sondern einen, der zeigt, wie es geht. Und da eine Warteschlange und ein Threadpool mir bekannte Konzepte schienen, habe ich das eben für möglich gehalten. Tut mir leid, dass ich Sie damit nicht so richtig "abgeholt" habe.
Wenn ich in einer Beratung keinen Code sehen will, dann steht dahinter aber ein anderer Grund. Da geht es eben meist nicht wirklich um Code. Das Problem liegt da woanders. Bei der CCR ist aber eben der Code das Problem. Deshalb auch gleich Code. (Mit ein wenig allgemeiner Vorrede.)
Schauen wir mal, wie das Feedback insg. ausfällt.
-Ralf Westphal
Threadpool + Queue sind natürlich bekannte Konzepte, aber die CCR ist doch deutlich mehr. Sie haben in ihren CCR Artikeln in der dotnetpro ein paar Grafiken verwendet, welche hier sicherlich ganz gut gepasst hätten.
@teichgraf: Wenn die Szenarien komplizierter geworden wären, hätte ich sicherlich auch Grafiken gezeigt. Aber die Demo drehte sich ja nur um 1 Komponente.
Die meisten Grafiken in den Artikeln haben auch mit den Unterschieden zw Multithreading und Multitasking zu tun. Sie zeigen, wie Taskschritte parallel oder sequenziell verarbeitet werden. Auch das wollte ich bewusst im Vortrag nicht thematisieren.
Aber ich höre Ihre Meinung und überlege, beim nächsten Vortrag zum Thema etwas mehr zu visualisieren. Der ist im Oktober auf der ADC in Bonn. (Das wird mir auch leicht fallen, weil ich dort 90min Zeit habe ;-)
-Ralf Westphal
Ich habe den Vortrag auf der SET live gesehen und empfinde Ralf's Beschreibung "sie schienen am Ende alle zufrieden" als Understatement par excellence - der Beifall war einem Highlight der SET angemessen, und ich begeistert, zugegeben. Die Eröffnung mit einem an das Flipchart geschriebenen Kommando an das Publikum hat eindruckvoll visualisiert, das verteilte, eigenständige Komponenten eine Infrastruktur zum Kommunizieren brauchen und CCR schien danach, wie eine der Natur nachempfundene Entwicklung. Der Code war einfach, hilfreich und vor allem lesbar und clean. Ach - und am Schluss liefen die Komponenten plötzlich in getrennten Prozessen - eindrucksvoll, überzeugend, durch und durch nachvollziehbar, und so nützlich, wenn man ein paar mehr Cores für sich arbeiten lässt... Danke!
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.