Threadprogrammierung

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Hallo!

Kennt von Euch jemand ein wirklich gutes Tutorial über Multithreadprogrammierung?
Habe bisher (über google) nur Tutorials gefunden, die auf die Windows-API aufsetzen. Befürchte nur, dass solche Programme dann nicht unter Linux laufen, was aber unbedingt der Fall sein soll...
Habe eben noch das im Lazarus-Wiki gefunden; ist aber leider noch wenig ausführlich...

Viele Grüße, Euklid

monta
Lazarusforum e. V.
Beiträge: 2809
Registriert: Sa 9. Sep 2006, 18:05
OS, Lazarus, FPC: Linux (L trunk FPC trunk)
CPU-Target: 64Bit
Wohnort: Dresden
Kontaktdaten:

Beitrag von monta »

also ich find das ganz gut, hat mir zumindest sehr geholfen, weiß gerade allerdings nicht mehr, in wie weit das auf die API aufsetzt.

http://www.michael-puff.de/Developer/Delphi/Tutorials/Threads_mit_Delphi.pdf

(hast du wahrscheinlich eh schon gefunden)

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

monta hat geschrieben:(hast du wahrscheinlich eh schon gefunden)


Ja, ich hatte es tatsächlich schon gefunden. :)
Trotzdem danke.

Die Überschrift "Threadprogrammierung unter Windows mit Delphi" deutet darauf hin, dass man die Methoden leider nicht mit Linux verwenden kann. Werde mir das Dokument trotzdem mal genauer ansehen...

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

ab 8. Das VCL Thread objekt ist alles platformunabhängig.

TThread kapselt alles was mach brauch einfach eine klasse von TThread baleiten procedure Execute; überschreiben und das wars schon im grossen und ganzen mit Create(False) wird er erstellt und gleich gestartet (Alles was in execute steht wird ausgeführt) mit Create(True) wird er Suspended erstellt und man kann ihn mit Resume laufen lassen Suspend hält ihn an Resume setzt ihn fort

alles was mit gui elementen oder nicht Thrtead eigenen funktionen arbeitet muss in eine extra procedure ohne parameter gepackt werden und min Synchronize(@Meinefunktion) aufgerufen werden.

Das ist eigentlich auch schon alles.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Threads

Beitrag von Euklid »

Zunächsteinmal: Habe bisher nicht sonderlich viel mit Threads gemacht.

christian hat geschrieben:ab 8. Das VCL Thread objekt ist alles platformunabhängig.

TThread kapselt alles was mach brauch einfach eine klasse von TThread

Aah. Das heißt, ich kann das Tutorial "Thread Programmierung unter Windows mit Delphi" genauso gut für Lazarus unter Linux verwenden? Welche Unit muss ich dazu einbinden, dass das funktioniert oder reicht Test=class(tthread)?

baleiten procedure Execute; überschreiben und das wars schon im grossen und ganzen mit Create(False) wird er erstellt und gleich gestartet (Alles was in execute steht wird ausgeführt) mit Create(True) wird er Suspended erstellt und man kann ihn mit Resume laufen lassen Suspend hält ihn an Resume setzt ihn fort

ahaa. Gute Information!

alles was mit gui elementen oder nicht Thrtead eigenen funktionen arbeitet muss in eine extra procedure ohne parameter gepackt werden und min Synchronize(@Meinefunktion) aufgerufen werden.

Das ist eigentlich auch schon alles.


Gut, danke.

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

hehe, da hatten wir wohl die selbe Idee ;)

Kannst ja meine Antwort hier reinkopieren...

//ok, zusammengefügt und die uninteressanten Beiträge hab ich mal gelöscht ;) , monta

perfekt! :)

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

Christian hat geschrieben: alles was mit gui elementen oder nicht Thrtead eigenen funktionen arbeitet muss in eine extra procedure ohne parameter gepackt werden und min Synchronize(@Meinefunktion) aufgerufen werden.


Dabei sollte man sich aber darüber klar sein, wie Synchronize funktioniert:

- Thread sendet Message an Mainthread
- Thread legt sich schlafen
- Mainthread tut irgendetwas, was sehr lange dauern kann (pi auf eine Million stellen ausrechnen, wenn der Programmierer das verlangt hat)
- Mainthread ist fertig (oder Mainthread ruft Application.ProcessMessages auf)
- das Synchronize Ereignis ist das nächste zu behandelnde (es könnten diverse andere ja vorher eingetroffen sein)
- Der Mainthread ruft die synchronisierte Prozedur auf
- Die synchronisierte Prozedur ist fertig
- Der Mainthread weckt den Thread wieder auf
- Der Mainthread wartet auf oder bearbeitet die nächste Message.

Mit Synchronize kann der Thread also beliebig lange verzögert werden. Das ist i.A. nicht das, was man mit Threads will.

Besser geht so etwas durch direktes Senden einer Message an den Main Thread. Das ist aber in FP noch nicht plattformunabhängig (ich habe vor, mich Anfang des Jahres darum zu kümmern). Problem dabei: Da der Thread und der Mainthread gleuichzeitig laufen, muss man sich intensiv Gedanken über die gemeinsam verwendeten Daten machen (z.B. TThreadlist anstelle vn TList verwenden und selber mit TCriticalSection die Zugriffe synchronisiern. Hierdurch entstehen zwar auch Verzögerungen, die kann man aber nach Bedarf sinvoll gestalten.

-Mcihael

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

Christian hat geschrieben:wird er Suspended erstellt und man kann ihn mit Resume laufen lassen Suspend hält ihn an Resume setzt ihn fort


Vor Kurzem hatte FP unter Linux Probleme mit Suspend/Resume. Ich weiß nicht, ob die bei der in Lazarus aktuell verwendeten Version komplett behoben sind.

-Michael

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

@mschnell
Über die Probleme mit Synchronize sollte sich jemand der mit thread programmierung anfängt nicht allzuviel gedanken machen man muss die leute nicht gleich mit informationen erschlagen. Wichtiger ist das ohn den Aufruf über synchronize nicht ganz so schöne dinge passieren können. Und wenn man Sachen in threads auslagert warum soll man dann das Hauptprogramm noch komplexe berechnungen durchführen lassen ich find die Aussage n bissle sinnlos.

Ich weiss auch nicht ob es behoben ist, hab mich schon eine weile nicht drum gekümmert da ich es mit criticalsections "emuliert hab"

@Euklid ja kannst das Tuturial so einsetzen
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Danke für die Antworten! Weitere Fragen kommen bestimmt... ;)

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

Wer mit Threads programmiert, sollte wissen, dass Synchronize den Thread aufhält und dass man das bis zu einem gewissen Grad durch Programmierung im Main-Thread (z.B. Application.ProcessMessages) verbessern kann.

IMHO ist die Verwendung von "Suspend" für laufende Threads sowieso keine sehr saubere Sache (der Thread bleibt irgendwo, u.U. mitten in einer Delphi-Instruktion stehen) . CriticalSection scheint mir viel "professioneller".

Und wie gesagt, hoffe ich, Anfang des Jahres eine portable und hoffentlich Benutzerfreundliche Alternative zu Synchronize zu basteln, die eine Parallel-Arbeit der Threads erlaubt (was natürlich noch mehr Aufmerksamkeit bei gemeinsam genutzten Daten verlangt als Synchronize.

-Michael

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

Ich habe gerade gesehen, dass es in FP eine platformunabhängige encapsulierung von pipes gibt (http://lazarus-ccr.sourceforge.net/docs ... index.html)
"The Pipes unit implements streams that are wrappers around the OS's pipe functionality. It creates a pair of streams, and what is written to one stream can be read from another."

Ich sehe allerdings nicht, ob und wie dabei realisiert ist dass ein Thread optional auf das Eintreffen einer Message aus einer Pipe warten kann.

Michael

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Danke schonmal für die Recherchen!
Leider habe ich keine Ahnung, was eine pipe ist :lol:

Wikipedia verrät folgendes:
Der Begriff Pipe (engl. für Rohr, Röhre) bezeichnet in der Informatik eine gepufferte Datenverbindung zwischen zwei Prozessen nach dem First-In-First-Out-Prinzip


Zusammen mit deiner Aussage interpretiere ich: Diese Pipes sind auch für die systeminterne Kommunikation zwischen den Programmen zuständig.
Aus der von dir zitierten Aussage würde dann folgen: Bei der Programmierung mit FPC ist die systemintere Kommunikation OS-unabhängig. Ich interpretiere weiter: Threadprogrammierung funktioniert mit Lazarus unter Linux genauso wie unter Windows. Diese Aussage würde sich dann mit der von Christian decken, glaube ich.

Liege ich richtig?

paradox
Beiträge: 34
Registriert: Fr 15. Sep 2006, 14:33

Beitrag von paradox »

Auch ich schreibe mit Freepascal und Threads, deshalb gebe ich auch mal meinen Senf hinzu :D.

Threadprogrammierung funktioniert mit Lazarus unter Linux genauso wie unter Windows. Kann ich nur bestätigen, bis jetzt hatte ich unter beiden Plattformen keine Probleme.

Pipes werden gern zur Uebertragung von Asynchronen nachrichten zwischen Threads verwendet, leider muss ich hinzufügen, dass ich mit den Pipes bis jetzt noch keine guten Erfahrungen gemacht habe.
Ich habe eine geschrieben um Asynchron Nachrichten auf Threads zu verteilen, falls hier bedarf besteht koennte ich sie zuschicken.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

paradox hat geschrieben: leider muss ich hinzufügen, dass ich mit den Pipes bis jetzt noch keine guten Erfahrungen gemacht habe.

In wie fern ?
paradox hat geschrieben: Ich habe eine geschrieben um Asynchron Nachrichten auf Threads zu verteilen, falls hier bedarf besteht koennte ich sie zuschicken.

Das würde mich interessieren. Kann ein Thread optional ohne pollen auf eine Nachricht warten oder aber auch testen ob eine Nachricht da ist und wenn nicht etwas anderes machen ? Ideal wäre auch die Möglichkeit auf mehrere Pipes gleichzeitig zu warten und bei Eintreffen irgendeiner Nachricht diese gezielt zu bearbeiten.

Wäre es sinnvoll das standardmäßig in FP zu integrieren ?

-Michael

Antworten