Threadprogrammierung
-
- 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:
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
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
-
- 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:
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)
http://www.michael-puff.de/Developer/Delphi/Tutorials/Threads_mit_Delphi.pdf
(hast du wahrscheinlich eh schon gefunden)
-
- 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:
Ja, ich hatte es tatsächlich schon gefunden.monta hat geschrieben: (hast du wahrscheinlich eh 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...
-
- 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:
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.
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/
-
- 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
Zunächsteinmal: Habe bisher nicht sonderlich viel mit Threads gemacht.
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)?christian hat geschrieben: ab 8. Das VCL Thread objekt ist alles platformunabhängig.
TThread kapselt alles was mach brauch einfach eine klasse von TThread
ahaa. Gute Information!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
Gut, danke.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.
-
- 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
Dabei sollte man sich aber darüber klar sein, wie Synchronize funktioniert: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.
- 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
-
- 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:
@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
Ü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/
-
- 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
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
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
-
- 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
Ich habe gerade gesehen, dass es in FP eine platformunabhängige encapsulierung von pipes gibt (http://lazarus-ccr.sourceforge.net/docs ... index.html" onclick="window.open(this.href);return false;)
"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
"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
-
- 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:
Danke schonmal für die Recherchen!
Leider habe ich keine Ahnung, was eine pipe ist
Wikipedia verrät folgendes:
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?
Leider habe ich keine Ahnung, was eine pipe ist

Wikipedia verrät folgendes:
Zusammen mit deiner Aussage interpretiere ich: Diese Pipes sind auch für die systeminterne Kommunikation zwischen den Programmen zuständig.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
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?
Auch ich schreibe mit Freepascal und Threads, deshalb gebe ich auch mal meinen Senf hinzu
.
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.

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.
-
- 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
In wie fern ?paradox hat geschrieben: leider muss ich hinzufügen, dass ich mit den Pipes bis jetzt noch keine guten Erfahrungen gemacht habe.
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.paradox hat geschrieben: Ich habe eine geschrieben um Asynchron Nachrichten auf Threads zu verteilen, falls hier bedarf besteht koennte ich sie zuschicken.
Wäre es sinnvoll das standardmäßig in FP zu integrieren ?
-Michael