Zirkuläre Flüsse

[Denis]

Wer hat schon mal Regelsysteme oder rückkoppelnde Systeme mit Flow-Design modelliert?
Das ist nicht trivial. Es ist eine spezielle Klasse von Systemen, für die sich im Flow-Design zirkuläre Nachrichtenflüsse ergeben. Und wenn man das Design unbedacht angeht, geht's schief.
Für alle Flow-Design-Implementierungen, ob EBC, NPantaRhei oder ScalaFlow, sind hier Besonderheiten zu beachten.
Ich habe dies versucht in einem Artikel zu beleuchtet: http://blog.grammarcraft.de/2014/02/08/kreisfluss-rueckgekoppelte-systeme-mit-flow-design/
Denis

[Ralf Westphal - One Man Think Tank]

Solche Rückkopplung tritt bei Konsolenprogrammen schnell auf, wo der Fluss so aussieht:

UI -> Verarbeitung -> UI

Dort ist keine Messageloop am Werk wie beim GUI. Und dann kann es potenziell zu Stackoverflows kommen.
Aber das lässt sich natürlich leicht lösen, wenn man es weiß.

NPantaRhei bietet u.a. dafür unterschiedliche scheduling strategies. Beim sync scheduling, kann es zum Overflow kommen. bei den async strategies nicht. Weil da intern schon async gearbeitet wird. Das muss man nicht extra beim Zusammenbau des Flows einschalten, wie du es in deinem Blogartikel getan hast.

-Ralf

Denis

8. Februar 2014 15:12

--
Mein aktuelles Kindle eBook: "Messaging as a Programming Model - OOP as if you meant it"

Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
22085 Hamburg
Germany

in...@ralfw.de
@ralfw
www.ralfw.de
blog.ralfw.de

[Denis]

Ralf, Du hast natürlich recht, man kann auch das Scheduling ändern. Es ist eine globale Änderung. Meine Änderung -- eine Action, deren Nachrichten im Flow "zurückfliessen", als asynchron zu markieren -- ist minimal.
Aber vielleicht sollte das asynchrone Scheduling als Default- Scheduling voreingestellt werden? Damit funktionieren zirkuläre Flüsse mit der Flow-Runtime dann immer "out-of-the-box".
Aber im Artikel ging es vor allem darum, das Problem aufzuzeigen. Ich wolltecauch zeigen, dass externe DSLs den Vorteil haben, auf Ihnen Konsistenz-Checks wie Zyklusprüfungen auf der Abstraktionsebene der Sprache laufen lassen zu können, was bei komplexeren Flow-Designs (und hoffentlich werden sie mit der Zeit komplexer ;-) durchaus sehr hilfreich sein kann. ... So zu sagen, eine generelles Plädoyer für ein besseres Toolong.
Denis

[Ralf Westphal - One Man Think Tank]

Das Scheduling war früher per default auf async. Ich hab es dann umgestellt, weil das der üblichen Denke zu sehr widerspricht.
Jetzt ist sozusagen als Sicherung der default sync. Aber man kann ja umstellen.

Denis

9. Februar 2014 22:47

Ralf Westphal - One Man Think Tank

8. Februar 2014 20:20

[Mike Bild]

Hey Denis, Hey Ralf,

@Denis: spannender Vergleich zu Regelkreise aus der Steuerungs- und Regelungstechnik  bzw. Automatisierungtechnik. Das werde ich in meinen Beispielen mit einbeziehen.

@Ralf: Sehr schade, dass "async" der üblichen Denke zu sehr widerspricht. Ich bin da ebenfalls Denis seiner Meinung. Async, hier vielleicht noch eine genauere Bezeichnung Non-Blocking I/O, halte ich für den neuen "Default". Damit meine ich natürlich nicht Multithreading, sondern eben async Verarbeitung innerhalb eines Message-Loop auf einem Thread und Entkopplung durch eine Queue.

Und genau hier macht aus meiner Sicht eine Klassifizierung der "Bausteine" Sinn.

A) Für I/O (In->Process->Out / UI -> Verarbeitung ->UI) machen, auch aus genannten Gründen, nur Non-Blocking Bausteine wirklich Sinn. Hier greift ein übliches Observer-Pattern mit entsprechender Engine.

B) Für alle logischen Teile würde ich möglichst immer auf sync Bausteine zurückgreifen. Aus meiner Sicht sind die meisten Algorithmen sequentielle Abläufe. Eine async Strategie würde hier wie von Ralf bereits festgestellt zu sehr von der eigentlichen Lösung ablenken.

Ich meine, aus der Monadentheorie lassen sich einiger der Konzepte bereits gut adaptieren und dann auch entsprechend vermitteln.

Unfold -> In

Bind -> Process

Fold -> Out

Solange Daten in "In" und "Out" non-blocking verarbeitet werden, sind hiermit In->Process->Out->In  natürlich auch Implementierung als Regelkreise möglich.

Cheers, Mike

--

i...@ralfw.de
@ralfw
www.ralfw.de
blog.ralfw.de

[Denis]

Ja, Regelkreise sind eine spezielle technische Form rückkoppelnder Systeme, aber eher eindimensional bestimmt, sie regeln meistens eine Größe. Infomationelle rückkoppelnde Systeme sind meistens mehrdimensional, sonst würde man sie nicht als Informationssysteme realisieren sondern gleich in Schaltungen gießen.

Für die Optimierung der Scheduling-Strategie der Runtime lohnt es sich wirklich mal in das Scala-Actor-Paper reinzusehen. Die haben eine Lösung gefunden, die vorangig synchron arbeitet, also quasi über direkte Methodenaufrufe und nur bei Notwendigkeit auf async ausweicht.

@Mike: Was meinst Du mit Monadentheorie? Die von Leibniz?

Denis

[Mike Bild]

@Moande: http://en.wikipedia.org/wiki/Monad_(functional_programming)

Nein, genau darum geht es ja - im übrigen mittels Monade. Mach aus etwas "einfachen" eindimensionalen mittels mehrfacher Kombination etwas Komplexes. Das ganze so dynamisch und flexibel wie möglich. Daraus entstehen, wie bsw. viele Standardschaltkreise aneinander geschaltet, komplexe Informationssysteme. So lassen sich in der Digitalelektronik "einfache" Regelkreise zu komplexen Regelkreisen verschalten. Und genau das ist auch gut so ;-).

Ich kenne das Scala-Actor-Paper nicht, bin aber nach deinen Schilderungen erstmal kein Freund von "Mache Async irgendwie magisch ähnlich zu Sync." Ich bin davon überzeugt, dass async soweit möglich so explizit wie möglich gemacht werden sollte und das als "default" für I/O.

Cheers, Mike