Parallelisierung ist eines der faszinierendsten Themen in der Programmierung! Parallelisierung (oder Threading) ist eines der herausforderndsten Themen in der Programmierung! Was jetzt?
Ehrlich: beides stimmt – eben wie im echten Leben: häufig ist das, was faszinierend ist auch problematisch! Nehmen wir Bergsteigen oder Parachuting. Wer’s ohne Kondition und Training macht, trägt ein hohes Risiko. Aber kommen wir zurück zum Programmieren, zurück zu Java.
Im Fall von Java wird die Parallelisierung i.W. durch die class Thread und das Interface Runnable unterstützt. Häufig wird die Parallelisierung auch als Threading bezeichnet. Letztlich sind die beiden Begriffe synonym.
Vielleicht fragen Sie sich an dieser Stelle, ob das Titelbild zum Blogpost von Relevanz für ADRELI_2_Thread ist? Nun ja, siehe dazu, was das Ende der Story sagt.
Am Rande sei bemerkt, dass es auch Programmiersprachen gibt, die kein Parallelisierungskonzept enthalten, weil die Parallelisierung mit Hilfe von System-Calls des Betriebssytems (Einsprung ins Betriebssystem und Nutzung einer Betriebssystemfunktion) realisiert werden. Diese Art der Parallelisierung ist natürlich nicht identisch mit dem Threading: weil i.d.R. jetzt Prozesse (und nicht einzelne Threads) parallelisiert werden. Aus Architektursicht sind die Konzepte quasi identisch. Aus Performancesicht ist die Prozess-Parallelisierung (ursprünglich) etwas schwerfälliger. Diese “Schwerfälligkeit” wird allerdings heute i.d.R. durch die Hardware “weg-egalisiert” und ist damit (fast) kein Argument mehr gegen die Prozess-Parallelisierung.
…Naja stimmt nicht ganz: die Kerne der Prozessoren nehmen zu und damit muss auch die Parallelisierung zur Nutzung der Prozessorkerne intensiv genutzt werden. Sonst wird diese Hardware-Entwicklung ja nicht wirklich unterstützt.
Im Fall von Java bietet sich die Nutzung von System-Calls nicht so an, Java-Programme sollen ja portabel sein, diesbezüglich ist die Nutzung von betriebssystemspezifischen System-Calls ganz offensichtlich kontraproduktiv!-Besser nicht!
2. Sprint: ADRELI_2_Threading
Im Blogpost vorher wurde ja schon einiges zum 2. Sprint gesagt. Um’s lesen des Assignments kommt man nicht umhin. Einiges hat sich auch im Vergleich zu den Aufgabenstellungen der Vorsemester geändert, so dass frühere Implementierungen nicht mehr in Ordnung sind!
Es macht aber Sinn, früher verfasste Videos für das ADRELI_2_Threading Revue passiern zu lassen. Hier finden Sie die Videos in ihrer historischen und sachlich sinnvollen Reihenfolge der Übersicht halber zusammengestellt.
1. Parallelisierung: Besprechung des Projekts (ca. 30 Minuten)
Die monolithische Lösung wird zerlegt: in mehrere Threads. Sie Threads laufen verteilt in einer Java Visual Machine. Wissen aus Kapitel 6 des Skripts wird gebraucht: class Thread und interface Runnable. Warum sind ge-threadete Lösungen nicht mehr zeit-deterministisch. Was bedeutet das und welche Rolle spielt dabei der betriebssystemeigene Scheduler oder Dispatcher?
Warum müssen Threads miteinander kommunizieren? Welche Komunikationsmittel können Threads nutzen? Besonders bedeutsam: der kooperative Zusammenarbeit als Basis des Threadings von Java! Welche Art von Synchronisation ist für unsere Thread-Zusammenarbeit angesagt und wieso ist überhaupt die Synchronisation der Threads notwendig? Und was ist datenbasierte Integration? Was sind Piper und welche Rolle spielt MVC?
Fragen über Fragen! Diese und mehr erklärt das Video. Es wird nochmals die monolithische ein-Thread-Architektur (von Adreli_1_CON) im Gegensatz zur neuen MVC-Architektur von Adreli_2_Threads andiskutiert. Die beiden Architekturen werden also nebeneinander gestellt und besprochen.
Sie sollten nun mit ein paar einführenden Überlegungen gerüstet sein für die nachfolgenden Videos, vielleicht auch schon für die spätere Diskussion der Vorteil von Parallelität und verteilten Systemen.
Doch zunächst betrachten wir die grundsätzliche Struktur (Basis-Architektur) unseres anvisierten ADRELI_2_Thread-Programms im folgenden Videobeitrag. Siehe auch Felix “scaffold_0…“Die beiden Architekturen werden also nebeneinander gestellt. Beachten Sie: wir werden die Threads durch den Einsatz der Kommunikationskanäle “pipes” synchronisieren – das ist im folgenden Videobeitrag noch ausgeblendet. Pipes werden später diskutiert.
2. Parallelisierung: Grundstruktur ohne Piping (ca. 45 Minuten)
Parallelität (auch Concurrency genannt) läßt den Faktor “Zeit” beim Programmieren relevant werden. In welcher Weise? Die Methoden-Aufruf-Semantik ändert sich jetzt! Wie? Das wird im Video gezeigt! Und überhaupt, was ist die “Calling-Sequence“. Beim Threading kommt einiges zusammen, was beim Aufruf von run() mit Hilfe von start() zusammen kommt. Welche Rolle welcher Thread im Rahmen der MVC-Architektur spielt wird natürlich auch gezeigt und warum wir zwei Pipes einsetzen, für welche Aufgaben.
Dieses und mehr erklärt das Video, also unbedingt genau betrachten, vor allem auch, weil die Fallstudie “ErsterThread” besprochen wird (Sie finden die Fallstudie
im Felix-zip-File “PROMOD2_case_studies_illik_release_13“.
Der Einsatz der Pipes fehlt hier zwar noch, aber die Architektur, die hier gezeigt wird, ist der Kern der Adreli_2_Thread-Architektur. Das Video bespricht die Fallstudie “ErsterThread” sehr detailliert – auch der fehlende Zeitdeterminismus wird beobachtet!
3. Andere Perspektive! Basis-Architektur ADRELI_2_Threads (ca. 30 Minuten)
Die jetzt gezeigte Architektur für ADRELI_2_THREADING ist jetzt schon nahe and der endgültigen Architektur von ADRELI_2. Zur Abwechslung sprechen wir hier in dieser Interimslösung über einen “Writer”-Thread und einen “Reader”-Thread. (Der eine Thread produziert Daten (= Writer-Thread) und der andere Thread konsumiert die Daten ( = Reader-Thread). In der Literatur sind auch die Begriffe “Produzent” und “Konsument” hierfür durchaus gängig. Den Zusammenhang zwischen MVC- und Writer-Reader- bzw. Produzent-Konsument-Sicht wird im Video verdeutlicht. Zahlreiche notwendige class Thread-Methoden kommen auch zu Einsatz.
Dieses und mehr erklärt das Video. Siehe auch Felix “scaffold_1…”. Dann fehlt nur noch der Einbau der Pipes!
4. Jetzt aber! ADRELI_2_Thread-Architektur mit Pipes (ca. 30 Minuten)
Jetzt kommen Pipes ins Spiel – etwas vereinfacht, nur eine Pipe. Adreli wird zwei Pipes brauchen. Was Sie in dieser CaseStudy hier schon sehen: wie der Controller die Infrastruktur in Betrieb nimmt ist hier aber schon gut erkennbar! Wie aber werden Pipes eingerichtet und in Betrieb genommen? Wie werden ein Pipe-Schreib-Ende mit einem Pipe-Lese-Ende verbunden? Was gibt es bei der Kommunikation über eine Pipe sonst noch zu beobachten, vor allem hinsichtlich der Synchronisation? Wir nutzen die automatische Synchronisation von Pipes!
Die Adreli_2-Threads sind hier auch zu einer Thread-Group zusammengefaßt. Wozu sind Thread-Groups aber nützlich? Und wie hängen das Setzen des Interrupt-Flags mit dem Exception-Handling zusammen? Und wieder schlägt der fehlende Zeitdeterminismus zu! Fragen über Fragen…. 🙂
Dieses und mehr erklärt das Video. Das müssen Sie anschauen und mit Eclipse nachbauen. Siehe auch Felix “scaffold_2…”.
5. Parallelisierung: Pipe-Fitting! Kommunikation über die Pipes (ca. 20 Minuten)
Im vorhergehenden Video haben wir zur Einführung des Pipe-Konzepts nur mit einer einzigen Pipe gearbeitet. Weil Pipes unidirektional sind (alle “Rohre” (als direkte Übersetzung vom engl. pipe). Rohre lassen (zu einem Zeitpunkt) nur Flüsse in eine einzige Richtung zu – zuhause gehen Reinwasser und Abwasser grundsätzlich auch durch zwei verschiedene Rohre 🙂 . So machen wir’s auch in Adreli_2: eine Pipe läßt den Info-Fluss vom View-Thread zum Model-Thread zu. Und eine zweite Pipe ermöglicht umgekehrt den Info-Fluß vom Model-Thread zum View-Thread. Wir brauchen also zwei Pipes für einen Dialog. Alles klar? Wie im Handwerkerleben erfährt die Programmierer/in hier auch: Rohre müssen zusammen passen! Das zu bewerkstelligen wird als Pipe-Fitting bezeichnet. (Suchen Sie im Skript nach “PIPE_FITTING“.) Auch darum dreht sich die CaseStudy, wie das Pipe-Fitting und die Kommando-Übertragung (Kommando = Auftrags-Code), samt Handshake, funktionieren kann… und was der pipeChecker() dabei übernimmt… 🙂
Dieses und mehr erklärt das Video. Danach sind Sie Threading- und Piping-Spezialist/in. Wow!
Nach dem Studium der Serie Game of Threads sollte die Implementierung der Acceptation Criteria gelingen! Fragen zum 2. Sprint zu SCRUM und zu Java beim nächsten Meeting!
Zu guter Letzt
Vielleicht fragen Sie sich, ob Sie nicht die provisorische Handskizze (links)
in ein professionelles UML Diagramm weiterentwickeln sollten? Gute Idee! Machen Sie das. Es wird Punkte bringen – versprochen! Sicherlich ist die Handskizze nicht optimal, wie gesagt.
Besser gefallen würde mir schon ein UML-Diagramm als Darstellung. Finden Sie raus, welche Diagramm-Art zu nutzen ist und besprechen vielleicht das UML-Diagramm sogar mit Ihrem UML-Prof. Sie signalisieren damit deutliches Interesse.
Fragen zum 2. Sprint, zu SCRUM und zu Java besprechen wir im nächsten Meeting.