RaDiBos dritte Anfängerfrage (EV - Multithreading)

[RaDiBo]

Guten Abend ihr alle zusammen

Beim Stöbern im Wiki habe ich gerade unter Wiki -> Anleitungen -> Erweiterte Zugsteuerung mit der Ereignisverwaltung

folgenden Abschnitt gefunden:

Zitat

Leider ist der hier beschriebene Mechanismus "Lockvariable auf 0 prüfen und dann auf eigenen Wert setzen" nicht "atomar". D.h. die Aktionsfolge "Lesen + Bewerten + Schreiben" kann nicht als "eine Operation" realisiert werden, während deren Bearbeitung konkurrierende Lese- und Schreib-Operationen unterbunden werden. Deshalb kann der Wert "0" aus der geprüften Lockvariable so lange auch durch andere Instanzen gelesen werden, bis sie mit einem anderen Wert überschrieben wurde. Damit führen auch diese Instanzen die Bearbeitung des Ereignisses 1 aus und überschreiben ihrerseits die vorgefundene (und vermeintlich noch gültige) "0" mit ihrem spezifischen Lock-Wert. Findet dieses Überschreiben durch die konkurrierenden Prozesse erst statt, nachdem die eigene Instanz die Zusatzbedingung in Ereignis 2 (erfolgreich) geprüft hat, nimmt diese an, dass sie den Lock besitzt, obwohl andere Instanzen ihn kurz darauf überschreiben, und bearbeitet das durch den Lock zu schützende Betriebsmittel nun, nicht wissend, dass sie den Lock überhaupt nicht mehr besitzt.

Bei einem Softwareker wie mir kommt da natürlich sofort der Verdacht auf das die EV vom MBS im Multithreading, vllt.sogar im Multicore Multithreading, abgearbeitet wird.

Ist das tatsächlich der Fall?

Wenn ja, wo gibt es eine nähere Beschreibung dazu die die Fragen "Was läuft parallel? Was läuft sequentiell? Was läuft atomar?" beantwortet?

Ich wünsche euch ein schönes We gehabt zu haben

RaDiBo

 

[Neo]

Hallo RaDiBo,

die EV läuft single-threaded, weshalb es keine konkurrierenden Zugriffe gibt. Alle Aktionen eines Ereignisses laufen direkt nacheinander ab, in der Reihenfolge, wie sie definiert worden. Löst eine Aktion selbst ein neues Ereignis aus, dann werden die Aktionen dort erst nach Abarbeitung aller aktuellen Aktionen verarbeitet.

Der von dir genannte Wiki-Artikel stammt von BahnLand, weshalb ich auch nicht direkt sagen kann, warum dort von konkurrierenden Zugriffen gesprochen wird, aber bestimmt wird er dies zeitnah aufklären.

Viele Grüße,

Neo

[RaDiBo]

Hallo Neo,

herzlichen Dank für diese promptfixe Antwort

Darf ich ihr auch entnehmen das nicht nur die Aktionen innerhalb eines Ereignisses sondern auch alle Ereigisse in den Ereignisgruppen nacheinander (von oben nach unten) abgearbeitet werden? Oder, mit anderen Worten: Das die Darstellung durch (geschachtelten) Ereignisgruppen nur der Übersichtlichkeit dient, die Ereignisse in Wirklichkeit aber so abgearbeitet werden wie sie bei einer rekursiven Top Down Baumsuche gefunden würden?

Herzliche Grüße

RaDiBo

 

[Neo]

Hallo RaDiBo,

vor 6 Minuten schrieb RaDiBo:

wie sie bei einer rekursiven Top Down Baumsuche gefunden würden?

das ist korrekt.

Viele Grüße,

Neo

[BahnLand]

Hallo Ralf,

bei der Beschreibung des Lock-Mechanismus im Wiki war mir nicht klar, dass die Ereignisverwaltung generell "single-threaded" ist und daher gleichzeittig miteinander konkurrierende Prozesse in der Ereignisverwaltung nicht möglich sind. Deshalb bin ich bei meiner Beschreibung auf "Nummer sicher" gegangen.

Ich war beruflich über viele Jahre in der Betriebssystem-Entwicklung für Großrechner tätig (hatte nichts mit Windows zu tun), und da mussten wir parallele Prozesse auf Multiprozessor-Systemen unterstützen. Dort gab es dann Hardware-Befehle, die genau die von mir beschriebene Serialisierung gewährleisteten, indem die jeweils anderen Prozessoren für den Ausführungszeitraum dieser "atomaren" Prüf-Schreib-und-Test-Operation angehalten wurden, wenn sie auf die den Lock repräsentierende Speicherstelle zugreifen wollten.

Wenn Neo (nach seiner obigen Aussage) garantiert, dass eine Ereignis-Bearbeitung grundsätzlich komplett abgearbeitet wird (Auslösung + Prüfung Zusatzbedingen + komplette Ausführung aller zugeordneten Aktionen), bevor ein weiteres Ereignis zur Abarbeitung gelangt, kann es zu den von mir beschriebenen "konkurrierenden" Aktivitäten nicht kommen. In diesem Fall ist das Aufziehen und Abarbeiten des Countdown-Ereignisses (Countdown-Aufruf im 1. Ereignis und komplettes 2. Ereignis in meiner Beschreibung) überflüssig.

Sollte jedoch in einer der nächsten Versionen des Modellbahn-Studios die Ereignisverwaltunng doch parallele Prozesse unterstützen, würden alle Ereignissteuerungen, die den "vereinfachten" Lock-Mechanismus (ohne Ereignis 2) verwenden, nicht mehr funktionieren. Es sollte also schon sichergestellt sein, dass auch in Zukunft zu einem Zeitüunkt immer nur eine einzige Ereignisbearbeitung durchgeführt werden kann, um "guten Gewissens" auf den vereinfachten Lock-Mechanismus zurückzugreifen.

Die von mir beschriebene Locksteuerung mit den 2 genannten aufeinanderfolgend abzuarbetenden Ereignisdefinitionen fiunktioniert dagegen auch bei einer möglicherweise zukünftig eingeführten Parallelisierung von Ereignisprozessen.

Viele Grüße
BahnLand

[RaDiBo]

Hallo Bahnland,

ich hoffe sehr das Du meine Frage im EP nicht als implizite Kritik aufgefasst hast! Mir ging es wirklich einzig um Wissensbeschaffung zu den Interna des MBS.

Wir beide haben wohl einen sehr ähnlich beruflichen Erfahrungsschatz; ich selbst habe mein ganzes Berufsleben lang interruptgetriebene Echtzeitsoftware für Embedded Controller entwickelt, seit Mitte der 1990iger im präemptiven Multithreading, seit Anfang 2000 im Multicore Multithreading. Die ganzen Fallstricke und Stolpersteine rund ums Recourcen Sharing, atomisierte Variablenzugriffe u.s.w. sind mir also auch höchst intim bekannt und haben mich anfangs beim Debugging so manchen Liter Kaffee, viele Packungen Ziggys und jede Menge Nervennahrung (Schoki) gekostet 

Was mich beim Lesen des zitierten Abschnittes des Wiki so stutzig werden lies war die Tatsache, daß ich in der bis dato von mir gelesenen/gesehenen Dokumentation zur EV noch an keiner anderen Stelle einen Hinweis auf irgendeine Form von Multithreading gefunden hatte. Neo ist sicherlich ebenfalls Softwareprofi und hätte daher in seiner Dokumentation (den Videotutorials u.s.w.)  deutlich auf dieses Feature und die daraus entstehenden Probleme hingewiesen (oder sie stillschweigend trickreich im EV Interpreter (oder ist es eine Art Compiler?) umschifft) denn das Problem der (nicht)atomisierten Variablenzugriffe würde ja jede Variable auf die in der EV an mehr als einer Stelle schreibend zugegriffen wird betreffen, nicht nur die von Dir sehr schön beschriebenen Lock- Mechanismen und Variablen.

Einen zukünftigen Übergang von streng sequentiell arbeitender EV zu einer parallelisierten Variante wäre in meinen Augen höchst problematisch; den würden Software Profis sicher mitgehen können aber diejenigen Kunden, die das MBS mit anderem Wissenshintergrund kaufen und einsetzen, wären damit meiner Einschätzung nach wahrscheinlich deutlich überfordert.

Herzliche Grüße sendet und einen gelungenen Wochenstart wünscht

RaDiBo

 

Bearbeitet 7. August 2017 von RaDiBo

[Neo]

Hallo,

die EV beschränkt sich ja vom Konzept her eher auf das Prüfen von Bedingungen und das Setzen von Eigenschaften. Selbst bei komplexen Anlagen stellt das im Moment noch lange keinen Performanceengpass dar, weshalb es von meiner Seite auch keine Pläne gibt, die EV um konkurrierende Zugriffe zu erweitern. In der Hinsicht muss es also keine Bedenken geben, dass in absehbarer Zeit eine ältere EV nicht mehr funktioniert.

Viele Grüße,

Neo

[BahnLand]

Hallo Ralf,

vor einer Stunde schrieb RaDiBo:

ich hoffe sehr das Du meine Frage im EP nicht als implizite Kritik aufgefasst hast!

nein, hatte ich nicht. Für mich war das einfach eine legitime sachliche Frage. Also kein Problem!

Viele Grüße
BahnLand