Nebenläufigkeit bei mehreren Threads

[RSE]

Hallo!

Wenn ich in meinem Programm alle Zugriffe von anderen Threads auf den Mainthread mit Synchronize kapsele, kann ich dann davon ausgehen, dass mir nichts dazwischenfunken kann (auch keine exportierten Funktionen), solange ich nicht Application.ProcessMessages aufrufe?

[theo]

Die Frage ist nicht leicht zu verstehen.
Application.Processmessages hat nicht viel mit "anderen Threads" zu tun, und was die exportierten Funktionen sind bzw. machen ist mir auch nicht klar.

[RSE]

Ich arbeite das erste mal mit Threads, daher bin ich mir noch nicht ganz so sicher über die Reihenfolge der Abläufe.

Wenn ich in einem Thread auf den Hauptthread zugreifen will, tue ich das mit Synchronize. Soweit ich weiß, wird dadurch meine Prozedur im Hauptthread ausgeführt, sobald dieser in die Botschaftsschleife eintritt. Das wiederum passiert, wenn entweder alles andere abgearbeitet ist, oder Application.Processmessages aufgerufen wird. Unter anderem diese letztere Annahme wollte ich durch diesen Post bestätigt bekommen.

Mit exportierten Funktionen meine ich Funktionen, die ich wie in einer dll nach außen verfügbar mache (mir fällt grad nich ein wie das heißt, aber ich glaube doch, dass das Schlüsselwort dafür "export" heißt). Ich nehme an, dass diese externen Aufrufe wiederum erst dann abgearbeitet werden, wenn mein Hauptthread in die Botschaftsschleife eintritt. Das ist die zweite Annahme, die ich bestätigt bekommen möchte.

[mschnell]

Wenn ich in meinem Programm alle Zugriffe von anderen Threads auf den Mainthread mit Synchronize kapsele, kann ich dann davon ausgehen, dass mir nichts dazwischenfunken kann (auch keine exportierten Funktionen), solange ich nicht Application.ProcessMessages aufrufe?

Ja. "Synchornize" legt den aktuellen Thread schlafen und führt die angegebene Methode im Mainthread aus. Erst wenn diese Methode beendet ist, läuft der Thread weiter.

Vorteil: einfacher in der Anwendung als richtige Inter-Thread-Kommunikation (z.B Messages).

Nachteil: Der Thread muss warten bis der Mainthread Zeit hat, das Event zu verarbeiten, also bis alle anderen vorher aufgetretenen Events abgearbeitet sind. Das kann natürlich sehr lange dauern. In vielen Fällen hatte man sich die Thread-Programmierung gleich sparen können.

Leider ist Synchronize die einzige in der RTL/LCL vorgesehene Plattform-unabhängige Methode von einem Thread aus Events im Mainthread (als asynchron/non-Blocking) aufzurufen.

Michael

[RSE]

Hm, ich modifiziere mal meine ursprüngliche Frage so, dass klarer zum Ausdruck kommt, was ich meine :

Wenn ich in meinem Programm alle Zugriffe von anderen Threads auf den Mainthread mit Synchronize kapsele, kann ich im Mainthread dann davon ausgehen, dass mir innerhalb der Abarbeitung einer Funktion (incl. Unterfunktionen/ aufgerufene Events ec.) nichts dazwischenfunken kann (auch keine exportierten Funktionen), solange nicht irgendwoin dieser Codefolge Application.ProcessMessages aufgerufen wird?

Sorry für die (im Nachhinein nachvollziehbar) unklare und missverständliche Fragestellung...

[Christian]

Ich glaube du willst auf callback funktionen hinaus. Das ist aber nicht einfach zu beantorten.
Das kommt schlichtweg auf deine dll an. Callback funktionen können jederzeit von der dll aufgerufen werden und damit kann der aufruf natürlich überall landen und auch nicht synchronisiert sein. Wenn du in der dll allerdings keine weitern Threads verwendest ist das ja nahezu unmöglich.

Beispiel:

Dein Programm ruf eine funktion in der dll auf (synchronisiert)
Die DLL ruft innerhalb der funktion 3x eine Callback auf ist natürlich dann auch synchronisiert

Ungünstig:

Dein Programm ruft in der dll eine funktion auf (synchronisiert)
Die dll startet einen thread und kehrt von der funktion zurück
Dieser ruft 3x die callback auf (unsynchronisiert !!!!!)

[RSE]

Nein, keine Callbacks. Kann ich denn nicht in meiner exe auch Funktionen exportieren, so dass andere exen meine exe als DLL benutzen können? Ist noch nicht implementiert, aber so könnte ich ja meine Grundfunktionalität (Mediaplayer ohne UI) anderen zur Verfügung stellen. Falls das so nicht funktioniert, würd ich es wohl über messages implementieren (vielleicht ist das sowieso der elegantere Weg?). Dann treffen mit Sicherheit die gleichen Einschränkungen bzgl. des Beginns der Abarbeitung zu, wie ich sie für Synchronize vermute. Sind die Vermutungen bzgl. der Einsprungzeitpunkte von Synchronize in den Hauptthread richtig?

[mschnell]

Sorry für die (im Nachhinein nachvollziehbar) unklare und missverständliche Fragestellung...

Verstehe ich immer noch nicht. Anhand der Erklärung, wie "Synchronize" funktioniert, solltest Du Dir aber jede diesbezügliche Frage selbst beantworten können.
-Michael

[mschnell]

Kann ich denn nicht in meiner exe auch Funktionen exportieren, so dass andere exen meine exe als DLL benutzen können?

Klar. Dann ist es aber keine exe, sondern eine dll. Kannst Du natürlich auch mit Lazarus erzeugen.

Andererseits kann die exe auch an die DLL einen Procedure-Pointer übergeben und die DLL kann die Procedure (oder Function) in der Exe als Callback aufrufen. (Das hat Christian gemeint.)
-Michael

[mschnell]

Sind die Vermutungen bzgl. der Einsprungzeitpunkte von Synchronize in den Hauptthread richtig?

Wie gesagt: Eine mit "Synchronize" angemeldete procedure wird (per event-queue) dann aufgerufen, wenn der Mainthread nichts mehr zu tun hat. Während die Prozedur auf die Bearbeitung wartet ist der Thread gestoppt. Erst wenn Wenn die Precedure komplett durch ist, bearbeitet sowohl der Mainthread das nächste Event als auch wird der Thread wieder gestartet. Da kann sich nichts beißen. "Synchronize" ist der "billige Jakob" der Inter-Thread-Kommunikation.

-Michael

[Christian]

@mschnell falls man schneller schreibt als man denkt gibts hier eine bearbeiten funktion mit der man den letzten beitrag noch um die neuen Erkentnisse der vergangenen 100 ms erweitern kann

@RSE das ese exe funktionen exportiert ist unter Windows möglich (auch ohne dlls) jedoch bin ich mir sehr unsicher darüber wie das in anderen betriebsystemen gehandelt wird und ob das "Feature" nicht plötzlich mal verschwindet das ist nämlich eigentlich nicht so gedacht... Normalerweise benutzt man dafür Bibliotheken (dll,so).

Ich finde für Interprozesskommunikation wird TCP/IP immer interessanter gerade aus dem Aspekt der Plattformunanbhängigkeit heraus.
selbst dbus gibts unter windows nicht richtig. Warum also nicht TCP/IP nehmen das beherscht mittlerweile jede Programmiersprache aus dem FF viel overhead ists auch nicht...

[RSE]

Wie gesagt, ich wollte eigentlich nur meine Vermutungen bestätigt haben, was mschnell in seinem 3. Beitrag in Folge ja jetzt getan hat

Zu den exportierten Funktionen: Wenn das nicht von allen OS unterstützt wird, werd ich das mal lassen. Dann werd ich das (falls ich es irgendwann tue) wohl über messages oder IP machen

Thx an alle Antworter, dass ihr euch durchgebissen habt

[mschnell]

Warum also nicht TCP/IP nehmen das beherscht mittlerweile jede Programmiersprache aus dem FF viel overhead ists auch nicht...

Soweit ich weiß, erzeugt TCP/IP in Windows sehr viel Overhead. In Linux wohl nicht.

-Michael

[mschnell]

Wenn das nicht von allen OS unterstützt wird, werd ich das mal lassen. Dann werd ich das (falls ich es irgendwann tue) wohl über messages oder IP machen

Leider gibt es. soweit ich weiß, für Messages auch keine Plattform-übergreifende Ekapsulierung in Lazarus .

-Mic hael

[RSE]

Leider gibt es. soweit ich weiß, für Messages auch keine Plattform-übergreifende Ekapsulierung in Lazarus .

Ich dachte, weil Lazarus ja auch selbst mit messages arbeitet wäre das so. Aber dann werden die wohl komplett intern verarbeitet, auch möglich. Wie macht man denn dann Teile der Funktionalität einer exe nach Außen hin plattformübergreifend ansprechbar? Ich will meinen Mediaplayer nicht in eine dll auslagern, um dann selbst mit der dll arbeiten zu müssen, möchte aber eventuell später die Funktionalität nach außen hin benutzbar machen, damit er auch von anderen Applications genutzt werden kann (ohne UI).