Inoffizielles deutsches Xbase-Forum

Hallo zusammen

eine Grundsätzliche Frage:

Ein Hauptprogramm erstellt ein Klassen Objekt mit verschiedenen Daten Array's und Variablen.

Das Klassen Objekt ist in vielen Threads sichtbar und die Threads schreiben und lesen alle die Daten in das gemeinsamte Objekt.
Die einem Thread zugeodneten Felder eines Array werden nur von genau diesem geschrieben jedoch von mehreren gelesen.

z.B { {Thread1},{Thread2} ....

Fragen:

Sehen alle Threads immer korrekte Daten in den Objekten Arrays und Felden?

Kann es vorkommen dass eine Variable im Klassen Objkt z.B. ein Array das ein anderer Thread liest KEINE oder FALSCHE Daten sieht?

Müssen solche gemeinsam genutzen Daten durch zusätzliche Vorkehrungen abgesichert werden?

hi,

wenn man mehrere Thread hat sollte man Signal() verwenden.

Hallo Jimmy

die Thread können / dürfen nicht auf einander Warten sondern müssen die vorhandenen Daten (Messwerte, Positionen usw.) verwenden.

Wenn das Klassenobjekt PUBLIC ist, verwenden alle Threads dieselbe Referenz. Damit müssten auch alle Instanzen immer synchron sein. Aber das ist eine komplexe Angelegenheit, würde ich vermuten. Das Symbol wird über die interne Tabelle mit den Publics verwaltet, und die Frage ist natürlich, was sich die Runtime im Moment des lesenden Zugriffs holt, wenn ein ACCESS auf eine Instanzvariable stattfindet, man also lesend auf sie zugreift. Damit wird ja eine Klassenmethode ausgeführt, und die Frage ist, wohin die Anfrage geht. Aber vermutlich ist das so gebaut, dass es das Objekt tatsächlich nur einmal gibt und dass es also in allen Threads jederzeit aktuell ist. Ich habe mit Publics jedenfalls noch keine gegenteiligen Erfahrungen gesammelt, auch mit solchen nicht, die Klassenobjekte enthalten.

Hallo Tom

ja, das dachte ich auch. Bekomme aber ab und zu NIL wo das gar nicht sein kann.

bewirkt, dass eine Methode nicht 2x gelichzeitig angesprunegn werden kann, sondern erst abgearbeitet wird und dann der nächste Aufruf kommt. Das könnte dir weiterhelfen.
Ich verwende aber nur Klasseninstanzen, keine public oder privat, in die in den Methoden geschrieben wird. Lies die Alaska Doku dazu

Also hatte Jimmy mit seinem Signal() nicht ganz unrecht. Das braucht man, um mit SYNC zu arbeiten.

SYNC Method sind unabhängig von Signal, wird dafür nicht benötigt.
SIGNAL dient dazu, den Fortschritt in 2 verschiedenen Threads zu kontrollieren

Im Beispiel zu SYNC wird mit Signal gearbeitet.

weil ein Thread auf den anderen wartet, das hat aber nichts mit Kapselung der Methodenausführung zu tun

Ich arbeite ebenfalls mit SYNC Methoden um sicherer zu stellen das immer nur ein thread in eine Datei schreiben kann.
Funktioniert auch super und ist auch genau dafür gedacht.

es gibt da das geniale Beispeil D:\Users\...\Documents\Xbase++\source\samples\basics\thread\coffee.exe. Das macht einfach Spaß.
Das Beispiel ist so inspirierend, dass man Lust hat, den Code anzusehen und zu analysieren.

I go and get me some coffee...

hi Carlo,

ramses hat geschrieben: ↑Mi, 19. Jan 2022 11:15 die Thread können / dürfen nicht auf einander Warten sondern müssen die vorhandenen Daten (Messwerte, Positionen usw.) verwenden.

über wie viele I/O Aktionen sprechen wir überhaupt
wenn du von Messdaten sprichst werden das wohl nicht wenig sein

---

eigentlich sind Signal() und SYNC beide falsch den im Prinzip geht es um das "Sperren" des Array bzw einer Cell.

Frage : kann man "Data-Object" im "Share" Modus nutzen und "sperren"

Man muss das Schreiben in das Dataobject einzig nur über EINE SYNC Methode ausführen, das ist dann atomar und sicher.
Du kannst einen Codeblock an die Methode übergeben und darin das Schreiben definieren.

Dito gilt für Arrays, vor allem wenn man Elemente löscht oder anhängt

Marcus Herz hat geschrieben: ↑Do, 20. Jan 2022 8:13 einzig nur über EINE SYNC Methode ausführen, das ist dann atomar und sicher.

Das versuche ich jetzt mal so umzusetzten und die Array's die beschrieben werden müssen noch mit EINER Sync Methode zu "bewirtschaften".

Nach Umbau der Datenfelder und entfernen der Public Variablen und den Daten-Objekts klappts nun.
Für den Thread übergreifenden Datenaustausch sind nun jeweils sync Methoden der jeweiligen Objekte zuständig.

So stehen z.B. die Daten der Geräte an Bus1 nur im Objekt / Thread welches den Bus1 bearbeitet.
Benötigt ein anderes Objekt/Thread Daten von Bus1 muss er es mit der Datenaustausch Methode des Bus1 Objekts anfordern.

Bis jetzt läufts fehlerfrei.