Synchronize für nonVCL

[Mr_G]

Hallo zusammen,
ich wollte mal fragen wie man nonVCL eine procedure eines anderen Threads aufrufen kann (die VCL-Klasse bietet dafür ja Synchronize...).
Gruß

Mr_G

[sirius]

Aufrufen kannst du sie immer. Es ist nur die Frage, ob du auf Daten aus dem Mainthread zugreifst. Dafür gibt es dann Critical Sections. Oder du nutzt Messages, oder....
Das kommt auf deinen Fall an.

[Apollonius]

Willst du nur ohne VCL programmieren oder auch ohne große Teile der RTL? Synchronize kann man auch ohne die VCL zum Funktionieren bringen.

[Mr_G]

Zitat:

Zitat von Apollonius

Willst du nur ohne VCL programmieren oder auch ohne große Teile der RTL? Synchronize kann man auch ohne die VCL zum Funktionieren bringen.

Wenn man es genau nimmt nonRTL (Visuelle Komponenten habe ich eh nicht).

Zitat:

Zitat von sirius

Aufrufen kannst du sie immer. Es ist nur die Frage, ob du auf Daten aus dem Mainthread zugreifst. Dafür gibt es dann Critical Sections. Oder du nutzt Messages, oder....
Das kommt auf deinen Fall an.

Also im moment nutze ich zur Ablaufsteuerung Events. Das funktioniert wunderbar. Das Problem ist folgendes:
Ich möchte nun einen Thread in einem Objekt starten.
Dann möchte ich aus dem Thread eine Methode des Objekts aufrufen.
Die Methode soll dann eine Callback-Funktion (Feld des Objekts) aufrufen (evtl. wieder aus einem anderen Thread).
Wie muss ich das anstellen damit es hier nicht kracht? Critical Sections bei den Zugriffen auf die Felder und die nicht lokalen Variablen?
Gruß

Mr_G

[Apollonius]

Das hängt alles davon ab, um was für Felder es sich handelt und wie sie verändert werden. Ich sehe es immer als Ziel an, möglichst ohne Locks irgendeiner Art auszukommen. Mit den Interlocked-Funktionen lässt sich sehr viel machen, z.B. kann man so Listen ohne Locks verwalten.

[Mr_G]

Im Prinzip geht es nur um diesen Pointer auf die Function. Der liegt aber wie gesagt in dem Objekt (also anderer Thread). Bisher habe ich da gar nichts gesichert, weil ich dachte es handelt sich beim Aufrufen dann nur um einen lesenden Zugriff. Leider gibt es aber in dem Umfeld sehr seltsame Fehler, daher dachte ich es könnte hieran liegen.

[Apollonius]

Ist das ein Funktionszeiger oder ein Methodenzeiger? Um einen Methodenzeiger threadsicher zu bewegen, muss man ein wenig tricksen.

[Mr_G]

Bei dem Callback handelt es sich um einen Funktionszeiger.
Aber... ich hab nochmal in den Code gesehen (Problem liegt schon etwas länger hier) und die Struktur ist noch etwas anders:
-> Thread erzeugt Objekt
-> Objekt erzeugt neuen Thread (übergibt Refernz auf sich an ThreadProc)
-> ThreadProc ruft nun eine Methode des Objekts auf die die eigentliche Aufgabe des Threads enthält
-> Diese Methode ruft nun eine weite Methode auf, die auf das Callback-Feld zugreift und die Funkion aufruft
Auch wenn es sich überladen anhört, von der Programmlogik her wäre es so in Ordnung, aber ich denke, dass es nicht treadsicher ist.
Diese Objekt macht das ganze etwas kompliziert.

[Apollonius]

Das hört sich eigentlich threadsicher an.

[Mr_G]

Wenn das wirklich so wäre, wäre das extrem dumm... Das eigentliche Problem ist wie gesagt älter und ich habs nochmal ausgegraben.
Ich kann mir einfach nicht erklären woran das liegt. Wenn man in meinem nonVCL/RTL-Fall keinen "Ersatz" für Synchronize braucht bin ich nun vollkommen planlos :pale:

[Apollonius]

Ist dir bewusst, dass du auch einen Service debuggen kannst?

[Mr_G]

Nein... aber ich lasse es mir gerne erklären...

[Apollonius]

Du musst den Service ganz normal starten und kannst dann mit Run -> Attach to process Delphi an den Service dranhängen.

[Mr_G]

Vielen Dank!
Ich werde mich dann nochmal mit einer genaueren Fehlermeldung melden (evtl. im anderen Thread...).