Multithreaded Application Tutorial/de: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1		-	\
2	1		Zurück zu den [[Additional information/de\|Zusätzlichen Informationen]].\
3		-	\
	2	+
4	3		== Überblick ==
5	4
6	5		Diese Seite soll zeigen, wie man unter FreePascal und Lazarus Multithread-Anwendungen erstellt und verwaltet. In einer Multithread-Anwendung lassen sich verschiedene Aufgaben auf mehrere Threads verteilen, die gleichzeitig ausgeführt werden können.
7	6
8	7		Wenn Sie bisher keinerlei Erfahrungen zur Multithread-Programmierung gemacht haben, empfehlen wie Ihnen, sich zunächst den Artikel "Benötigt Ihre Anwendung wirklich Multithread-Eigenschaften?" sorgfältig durch zu lesen, da Multithread-Programmierung kein leichtes Unterfangen ist.
9	8
10	9		Das Hauptziel der Multithread-Programmierung ist die Verfügbarkeit der Benutzeroberfläche eines Programms, während es im Hintergrund Berechnungen durchführt. Dies kann man erreichen, indem man die Berechnung in einen Thread außerhalb des sogenannten Main-Thread verlagert, welcher für die Aktualisierung der Benutzeroberfläche zuständig ist.
11	10
12	11		Andere Anwendungen, bei denen Multithread-Programmierung zum Einsatz kommt, sind Server-Anwendungen, die mehrere Klienten gleichzeitig betreuen müssen.
13	12
14	13		Multithread-Anwendungen ermöglichen auch die Aufteilungen der Lasten einer Berechnung auf mehrere Kerne einer Multi-Core-CPU.
15	14
16	15		Wichtig: Der Main Thread wird beim Start Ihrer Anwendung vom Betriebssystem erstellt. Der Main Thread ist dabei der einzige Thread (und muss auch der einzige bleiben), der für die Aktualisierung der Komponenten der Benutzeroberfläche zuständig ist (Forms, etc.) (ansonsten hängt sich Ihre Anwendung auf).
17	16
18	17		## Benötigt Ihre Anwendung wirklich Multithread-Eigenschaften?
19	18
20	19		Wenn Multithread Programmierung für Sie Neuland ist und Sie lediglich eine bessere Reaktionsfähigkeit ihrer Anwendung während langer Berechnungen benötigen, dann ist Multithreading nicht unbedingt die einfachste Lösung. Multithreading Applikationen sind immer schwieriger zu debuggen und auch oft viel komplexer. Außerdem benötigen Sie in vielen Fällen kein Multithreading, um ihre Anwendung reaktionsfähig zu halten. Statt dessen können Sie ein Application.ProcessMessages in Ihre Berechnungen mit einbauen. Dieses verarbeitet alle anstehenden Nachrichten, die an Ihre Applikation gesendet wurden und Ihre Applikation reagiert auf Ereignisse. Sie können also einen Teil der Berechnung durchführen, dann Application.ProcessMessages aufrufen und die Benutzereingaben werden verarbeitet und die Oberfläche neu gezeichnet. Platzieren Sie das Application.Processmessages z.B. in Schleifen, so dass bei jedem Schleifendurchlauf die Benutzeroberfläche reagiert.
21	20
22	21		Zum Beispiel: In den Lazarus-Beispielen unter examples/multithreading/singlethreadingexample1.lpi wird eine große Datei gelesen und verarbeitet und die oben genannte Technik benutzt.
23	22
24	23		Multithreading wird wirklich benötigt für:
25	24
26	25		- blocking handles, wie Netzwerkkommunikation, Interrupts (Linux)
27	26		- Mehrprozessor- oder Mehrkernbetrieb
28	27		- Algorithmen und Bibliotheksaufrufe, die nicht in mehrere kleine Stufen zerteilt werden können.
29	28
30	29		## Die Klasse TThread
31	30
32	31		Das folgende Beispiel ist im Verzeichnis examples/multithreading/ zu finden. Der einfachste Weg, um eine Multithread-Anwendung zu erstellen, ist die Verwendung der Klasse TThread. Über diese Klasse lässt sich, neben dem Main-Thread, ein zusätzlicher Thread in einfacher Weise erstellen. Unter normalen Umständen müssen dazu bloß zwei Methoden überschrieben (override) werden: Der Konstruktor Create und die Methode Execute. Im Konstruktor Create wird der Thread für die spätere Ausführung vorbereitet. Hier werden die dem Thread zugrunde liegenden Variablen initialisiert. Der originale Konstruktor des Threads enthält einen Parameter namens "Suspended": Damit der Thread nicht automatisch nach seiner Erstellung gestartet wird, ist es empfehlenswert, diesen Parameter auf "true" zu setzen. In diesem Fall können Sie den Thread zu einem späteren Zeitpunkt über die Methode "Resume" starten. Ist es dagegen erwünscht, dass der Thread direkt nach seiner Erstellung startet, setzen Sie Suspended auf "false".
33	32
34	33		Ab der Version 2.0.1 des FreePascal-Compilers lässt sich auch die Größe des von einem Thread verwendeten Stacks über einen Parameter des Konstruktor TThread.Create einstellen. Das kann beispielsweise bei rekursiven Prozeduren oder Funktionen nützlich sein. Wird die Größe des Stack nicht explizit festgelegt, verwendet FPC die vom Betriebssystem festgelegte Standardgröße.
35	34
36	35		In die (mit Parameter Override) überschriebene Methode Execute schreibt man den vom Thread auszuführenden Quelltext hinein.
37	36
38	37		Die Klasse TThread besitzt die wichtige Eigenschaft (property): Terminated : boolean; (Standardeinstellung: Terminated=false)
39	38
40	39		Der Sinn der Eigenschaft Terminated ist, dass sich ein Thread damit zu einem beliebigen Zeitpunkt abbrechen lässt. Jedoch muss dies von dem Programmierer in den Quelltext der Methode Execute eingearbeitet werden - die Methode Terminate greift also nicht direkt in den vom Programmierer vorgesehenen Programmablauf ein. Sollten sich in Ihrem Thread also Repeatschleifen oder andere sich wiederholende Stellen finden, ist es deshalb notwendig, dass Sie in jeder Schleife explizit prüfen, ob die Eigenschaft Terminated wahr oder falsch ist. Sollte Terminated=true sein, muss die Methode Execute (evtl. nach einer finalen Konfiguration) auf schnellstem Wege verlassen werden.
41	40
42	41		Wie eingangs erwähnt, sollte der erstellte Thread in keinem Fall mit den sichtbaren Komponenten der Benutzeroberfläche agieren. Die Benutzeroberfläche verändern, Eingaben abfragen, etc. darf ausschließlich der Main-Thread.
43	42
44	43		Um trotzdem aus einem Thread heraus auf die Benutzeroberfläche bzw. Variablen des Hauptprogrammes zuzugreifen, existiert die Methode Synchronize. Synchronize wird mit einer procedure als Parameter aufgerufen. Wenn Sie Synchronize(@MyMethod) aufrufen, wird der Thread gestoppt, der Code in MyMethod wird im Hauptthread ausgeführt, und dann die Bearbeitung des Threads fortgesetzt. Die exakte Arbeitsweise von Synchronize hängt von der Plattform ab.
45	44
46	45		Eine andere wichtige Eigenschaft (property) von TThread ist FreeOnTerminate. Wenn diese Eigenschaft auf True gesetzt ist, wird der Thread automatisch freigegeben (wie ein Aufruf von .Free), wenn Execute beendet wird. Beispiel:
47	46
48	47		``` pascal
49	48		Type
50	49		TMyThread = class(TThread)
51	50		private
52	51		fStatusText : string;
53	52		procedure ShowStatus;
54	53		protected
55	54		procedure Execute; override;
56	55		public
57	56		Constructor Create(CreateSuspended : boolean);
58	57		end;
59	58
60	59		constructor TMyThread.Create(CreateSuspended : boolean);
61	60		begin
62	61		FreeOnTerminate := True;
63	62		inherited Create(CreateSuspended);
64	63		end;
65	64
66	65		procedure TMyThread.ShowStatus;
67	66		// Diese Methode wird vom MainThread ausgeführt und kann deshalb auf alle GUI-Elemente zugreifen
68	67		begin
69	68		Form1.Caption := fStatusText;
70	69		end;
71	70
72	71		procedure TMyThread.Execute;
73	72		var
74	73		newStatus : string;
75	74		begin
76	75		fStatusText := 'TMyThread Starting...';
77	76		Synchronize(@Showstatus);
78	77		fStatusText := 'TMyThread Running...';
79	78		while (not Terminated) and ([any condition required]) do
80	79		begin
81	80		...
82	81		// here goes the code of the main thread loop
83	82		...
84	83		if NewStatus <> fStatusText then
85	84		begin
86	85		fStatusText := newStatus;
87	86		Synchronize(@Showstatus);
88	87		end;
89	88		end;
90	89		end;
91	90		```
92	91
93	92		In der Hauptunit erfolgt dann folgender Aufruf
94	93
95	94		``` pascal
96	95		var
97	96		MyThread : TMyThread;
98	97		begin
99	98		MyThread := TMyThread.Create(True); // So startet es nicht automatisch
100	99		...
101	100		// Here the code initialises anything required before the threads starts executing
102	101		...
103	102		MyThread.Resume;
104	103		end;
105	104		```
106	105
107	106		Soll Ihr Programm flexibler sein, können Sie ein Ereignis für den Thread erzeugen - Ihre synchronisierte Methode ist dann nicht eng an eine bestimmte Form oder Klasse gebunden und Listeners können mit dem Ereignis des Threads verbunden werden. Hier ein Beispiel:
108	107
109	108		``` pascal
110	109		Type
111	110		TShowStatusEvent = procedure(Status: String) of Object;
112	111
113	112		TMyThread = class(TThread)
114	113		private
115	114		fStatusText : string;
116	115		FOnShowStatus: TShowStatusEvent;
117	116		procedure ShowStatus;
118	117		protected
119	118		procedure Execute; override;
120	119		public
121	120		Constructor Create(CreateSuspended : boolean);
122	121		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
123	122		end;
124	123
125	124		constructor TMyThread.Create(CreateSuspended : boolean);
126	125		begin
127	126		FreeOnTerminate := True;
128	127		inherited Create(CreateSuspended);
129	128		end;
130	129
131	130		procedure TMyThread.ShowStatus;
132	131		// Diese Methode wird vom MainThread ausgeführt und kann deshalb auf alle GUI-Elemente zugreifen
133	132		begin
134	133		if Assigned(FOnShowStatus) then
135	134		begin
136	135		FOnShowStatus(fStatusText);
137	136		end;
138	137		end;
139	138
140	139		procedure TMyThread.Execute;
141	140		var
142	141		newStatus : string;
143	142		begin
144	143		fStatusText := 'TMyThread Starting...';
145	144		Synchronize(@Showstatus);
146	145		fStatusText := 'TMyThread Running...';
147	146		while (not Terminated) and ([any condition required]) do
148	147		begin
149	148		...
150	149		[here goes the code of the main thread loop]
151	150		...
152	151		if NewStatus <> fStatusText then
153	152		begin
154	153		fStatusText := newStatus;
155	154		Synchronize(@Showstatus);
156	155		end;
157	156		end;
158	157		end;
159	158		```
160	159
161	160		Und im Hauptformular
162	161
163	162		``` pascal
164	163		Type
165	164		TForm1 = class(TForm)
166	165		Button1: TButton;
167	166		Label1: TLabel;
168	167		procedure FormCreate(Sender: TObject);
169	168		procedure FormDestroy(Sender: TObject);
170	169		private
171	170		{ private declarations }
172	171		MyThread: TMyThread;
173	172		procedure ShowStatus(Status: string);
174	173		public
175	174		{ public declarations }
176	175		end;
177	176
178	177		procedure TForm1.FormCreate(Sender: TObject);
179	178		begin
180	179		inherited;
181	180		MyThread := TMyThread.Create(true);
182	181		MyThread.OnShowStatus := @ShowStatus;
183	182		end;
184	183
185	184		procedure TForm1.FormDestroy(Sender: TObject);
186	185		begin
187	186		MyThread.Terminate;
188	187		MyThread.Free;
189	188		inherited;
190	189		end;
191	190
192	191		procedure TForm1.Button1Click(Sender: TObject);
193	192		begin
194	193		MyThread.Resume;
195	194		end;
196	195
197	196		procedure TForm1.ShowStatus(Status: string);
198	197		begin
199	198		Label1.Caption := Status;
200	199		end;
201	200		```
202	201
203	202		## Worauf Sie achten sollten
204	203
205	204		Wenn Sie den Compilerswitch -Ct (Stack Check) benutzen, kann das einige Probleme mit sich bringen (Originalübersetzung: Es könnte Ihnen Kopfschmerzen bereiten :)) Aus unbekannten Gründen "triggert" der Stack Check an jedem TThread.Create, wenn Sie die Standardgröße des Stacks benutzen. Die einzige Lösung ist zur Zeit, -Ct nicht zu benutzen.
206	205
207	206		Um auf Exceptions im Thread zu prüfen, können Sie folgendermaßen vorgehen:
208	207
209	208		``` pascal
210	209		MyThread := TThread.Create(False);
211	210		if Assigned(MyThread.FatalException) then
212	211		raise MyThread.FatalException;
213	212		```
214	213
215	214		Dieser Code sorgt dafür daß Exceptions, die während der Erzeugung des Threads auftreten, im Main Thread einen Ausnahmefehler auslösen.
216	215
217	216		## Für Multithread-Anwendungen benötigte Units
218	217
219	218		Unter Windows benötigen Sie keine spezielle Unit, damit es funktioniert. Unter Linux, MacOSX und FreeBSD benötigen Sie die Unit cthreads und diese muss die erste verwendete Unit im Projekt sein (die Programm-Unit, .lpr)!
220	219
221	220		Daher sollte der Code Ihrer Lazarus-Anwendung etwa so aussehen:
222	221
223	222		``` pascal
224	223		program MyMultiThreadedProgram;
225	224		{$mode objfpc}{$H+}
226	225		uses
227	226		{$ifdef unix}
228	227		cthreads,
229	228		{$endif}
230	229		Interfaces, // dies bindet das LCL Widgetset ein
231	230		Forms
232	231		{ fügen Sie Ihre Units hier hinzu },
233	232		```
234	233
235	234		Wenn Sie dies vergessen, kommt die folgende Fehlermeldung:
236	235
237	236		` This binary has no thread support compiled in.`\
238	237		` Recompile the application with a thread-driver in the program uses clause before other units using thread.`
239	238
240	239		Lazarus Packages, die Multithreading beutzen, sollten -dUseCThreads zu den benutzerdefinierten Einstellungen für abhängige Pakete hinzufügen. Dazu öffnen Sie den Package-Editor für das entsprechende Paket, unter Einstellungen \> Bedienung \> Benutzerdefiniert fügen Sie -dUseCThreads hinzu. Dies wird diesen Compiler-Switch für alle Projekte und andere Packages, die dieses Package benutzen (die IDE eingeschlossen), definieren. Sowohl die IDE als auch alle von ihr neu erstellten Projekte, haben bereits folgenden Code in ihrer Projektdatei (.lpr):
241	240
242	241		``` pascal
243	242		uses
244	243		{$IFDEF UNIX}{$IFDEF UseCThreads}
245	244		cthreads,
246	245		{$ENDIF}{$ENDIF}
247	246		```
248	247
249	248		## SMP (Mehrprozessor) Unterstützung
250	249
251	250		Sobald Sie Threads benutzen, werden diese vom Betriebsystem auf mehrere Prozessoren verteilt.
252	251
253	252		## Debuging Multithread-Anwendungen mit Lazarus
254	253
255	254		Das Debuggen von Multithread-Anwendungen wird von Lazarus zur Zeit noch nicht vollständig unterstützt.
256	255
257	256		### Debugger Ausgabe
258	257
259	258		In einer Anwendung mit einem Thread (dem Hauptthread), können Sie einfach auf die Konsole in ein Terminal oder ähnliches schreiben und die Reihenfolge der Zeilen wird chronologisch so angeordnet sein, wie Sie es ausgegeben haben. In Multithreaded Anwendungen wird dies etwas komplizierter. Wenn 2 Threads schreiben, sagen wir, eine Zeile wird von Thread A und eine von Thread B geschrieben, dann ist nicht gesagt, dass sie zeitlich in der richtigen Reihenfolge erscheinen, bzw. es kann vorkommen, dass ein Thread dem anderen in die Ausgabe hineinschreibt.
260	259
261	260		Die Unit LCLProc enthält einige Funktionen, um jeden Thread seine eigene Logdatei schreiben zu lassen:
262	261
263	262		``` pascal
264	263		procedure DbgOutThreadLog(const Msg: string); overload;
265	264		procedure DebuglnThreadLog(const Msg: string); overload;
266	265		procedure DebuglnThreadLog(Args: array of const); overload;
267	266		procedure DebuglnThreadLog; overload;
268	267		```
269	268
270	269		Zum Beispiel: Anstelle von writeln('irgendein Text ', 123); verwenden Sie
271	270
272	271		``` pascal
273	272		DebuglnThreadLog(['irgendein Text ', 123]);
274	273		```
275	274
276	275		Dies wird eine Zeile 'irgendein Text 123' an die Log\<PID\>.txt Datei anhängen, wobei \<PID\> die Prozess ID des aktuellen Threads ist.
277	276
278	277		Es ist eine gute Idee, die Logdateien vor jedem Lauf zu entfernen:
279	278
280	279		``` bash
281	280		rm -f Log* && ./project1
282	281		```
283	282
284	283		### Linux
285	284
286	285		Das Debuggen von grafischen Multithreading-Anwendungen unter Linux funktioniert mittlerweile problemlos. In der Vergangenheit traten aber aufgrund von Kompatibilitätsproblemen dabei Probleme mit dem X-Server auf: Er stürzte ab.
287	286
288	287		Sollten bei Ihnen also solche Probleme auftreten, können Sie diese durch Starten einer neuen X-Instanz umgehen. Wie Sie dies erreichen, ist im Folgenden dargestellt. Eine andere Lösung ist bisher nicht bekannt.
289	288
290	289		#### X-Server in einem neuen Terminal starten
291	290
292	291		Starten Sie eine neue X-Instanz. Dies können Sie über die Konsole mit folgendem Befehl erreichen:
293	292
294	293		` X :1 &`
295	294
296	295		Nachdem Sie diesen Befehl ausgeführt haben, öffnet sich die neue X-Instanz. Mit den Tastenkombinationen \[Strg\]+\[Alt\]+\[F7\] und \[Strg\]+\[Alt\]+\[F8\] können Sie nun zwischen der Arbeitsoberfläche, auf der Sie arbeiten, und der neuen Instanz hin und her wechseln. (Bei der Slackware-Distribution und wenigen anderen wird dies durch die Kombination \[Strg\]+\[Alt\]+\[F2\] erreicht)
297	296
298	297		Als nächsten Schritt müssen Sie eine Desktop-Sitzung in der neuen X-Instanz starten. Starten Sie zum Beispiel eine neue gnome-Sitzung in der Konsole:
299	298
300	299		` gnome-session --display=:1 &`
301	300
302	301		#### X-Server in einem Fenster starten
303	302
304	303		Mit Xnest oder Xephyr können Sie auch einen X-Server in einem Fenster eines anderen X-Servers betreiben. Der Vorteil ist, dass Sie beim Debuggen nicht mehr zwischen verschiedenen Terminals wechseln müssen.
305	304
306	305		Mit dem Befehl
307	306
308	307		` Xnest :1 -ac`
309	308
310	309		starten Sie mit Xnest eine X-Sitzung auf :1 und deaktivieren die Zugriffskontrolle.
311	310
312	311		Unter GNOME können Sie auch folgenden Befehl verwenden:
313	312
314	313		` gdmflexiserver --xnest`
315	314
316	315		Dies startet nicht nur eine X-Sitzung; es wird auch gleichzeitig eine neue GDM-Sitzung, in der Sie sich anmelden können, gestartet.
317	316
318	317		#### Benötigte Einstellungen in Lazarus
319	318
320	319		Schließlich müssen Sie eine letzte Einstellung in Lazarus selbst vornehmen: Gehen Sie in der IDE in das Menü "Start"-\>"Start-Parameter...". Aktivieren Sie dort das Häkchen "Display verwenden", und tragen Sie in das Feld darunter die Zuordnungsnummer ":1" ein.
321	320
322	321		Jetzt wird die Anwendung auf dem zweiten X Server laufen und Sie sind in der Lage, sie vom ersten aus zu debuggen.
323	322
324	323		Dies wurde mit Free Pascal 2.0 und Lazarus 0.9.10 unter Windows und Linux getestet.
325	324
326	325		## Widgetsets
327	326
328	327		Die win32, gtk und carbon Schnittstellen unterstützen Multithreading vollständig. Das bedeutet, TThread, critical sections und Synchronize funktioniert.
329	328
330	329		## Critical sections
331	330
332	331		Eine critical section (kritischer Abschnitt) stellt sicher, dass in einer multi-thread Anwendung nicht gleichzeitig von verschiedenen Threads aus auf einen bestimmten Bereich des Codes zugegriffen wird. Bevor eine critical section benutzt werden kann, muss sie erstellt und initialisiert werden; wenn sie nicht mehr gebraucht wird, muss sie freigegeben werden.
333	332
334	333		Zur Verwendung von critical sections gehen Sie wie folgt vor:
335	334
336	335		Fügen Sie über uses die Unit SyncObjs hinzu, die die notwendigen Routinen beinhaltet.
337	336
338	337		Als nächsten Schritt deklarieren Sie die critical section (für alle Threads, die auf die section Zugriff haben sollen):
339	338
340	339		``` pascal
341	340		MyCriticalSection: TRTLCriticalSection;
342	341		```
343	342
344	343		Erstellen Sie die Section mit folgender Prozedur:
345	344
346	345		` InitCriticalSection(MyCriticalSection);`
347	346
348	347		Starten Sie einige Threads, die exklusive Aufgaben durchführen:
349	348
350	349		``` pascal
351	350		EnterCriticalSection(MyCriticalSection);
352	351		try
353	352		// An dieser Stelle können Sie auf Variablen zugreifen, Dateien schreiben, auf das Netzwerk zugreifen, u.s.w.
354	353		finally
355	354		LeaveCriticalSection(MyCriticalSection);
356	355		end;
357	356		```
358	357
359	358		Nachdem alle Threads, die Zugriff auf die critical section hatten, beendet wurden, müssen Sie sie nun deinitialisieren:
360	359
361	360		``` pascal
362	361		DoneCriticalSection(MyCriticalSection);
363	362		```
364	363
365	364		Alternativ können Sie die Klasse TCriticalSection benutzen. Das Erstellen eines Objektes der Klasse entspricht hier der Initialisierung, die Methode Enter entspricht obigem EnterCriticalSection, die Methode Leave entspricht der obigen LeaveCriticalSection und die Vernichtung (destruction) des Objektes erledigt das Freigeben.
366	365
367	366		Beispiel: 5 Threads, die einen einzigen Zähler erhöhen: lazarus/examples/multithreading/criticalsectionexample1.lpi
368	367
369	368		ACHTUNG: Sowohl die RTL als auch die LCL beinhalten beide obige 4 Funktionen. (Die Funktionen der LCL sind in den Units LCLIntf und LCLType definiert.) Beide erfüllen den gleichen Zweck. Sie können sowohl die Funktionen der RTL als auch die Funktionen der LCL zur selben Zeit in Ihrem Programm einsetzen. Sie sollten es nur vermeiden, die "critical section"-Funktionen der LCL auf die Funktionen der RTL anzuwenden und umgekehrt.
370	369
371	370		### Gemeinsamer Variablenzugriff
372	371
373	372		Mehrere Threads können sich eine Variable im Lesezugriff teilen, ohne dass Probleme zu erwarten sind. Nur wenn der eine oder andere Thread den Wert der Variablen ändern möchte, muss sicher gestellt werden, dass niemals mehrere Threads gleichzeitig auf die Variable zugreifen.
374	373
375	374		Als Beispiel: 5 Threads inkrementieren einen Counter: lazarus/examples/multithreading/criticalsectionexample1.lpi
376	375
377	376		## Wenn ein Thread das Ergebnis eines anderen benötigt...
378	377
379	378		Wenn ein Thread A das Ergebnis eines Threads B benötigt, muss er warten, bis B fertig ist.
380	379
381	380		Wichtig: Der Main-Thread sollte niemals auf einen anderen Thread warten müssen. Für diesen Fall benutzen Sie am Besten Synchronize (oben beschrieben).
382	381
383	382		Beispiel: lazarus/examples/multithreading/waitforexample1.lpi
384	383
385	384		``` pascal
386	385		{ TThreadA }
387	386
388	387		procedure TThreadA.Execute;
389	388		begin
390	389		Form1.ThreadB := TThreadB.Create(false);
391	390		// create event
392	391		WaitForB := RTLEventCreate;
393	392		while not Application.Terminated do begin
394	393		// wait infinitely (until B wakes A)
395	394		RtlEventWaitFor(WaitForB);
396	395		WriteLn('A: ThreadB.Counter=', Form1.ThreadB.Counter);
397	396		end;
398	397		end;
399	398
400	399		{ TThreadB }
401	400
402	401		procedure TThreadB.Execute;
403	402		var
404	403		i: Integer;
405	404		begin
406	405		Counter := 0;
407	406		while not Application.Terminated do begin
408	407		// B: Working ...
409	408		Sleep(1500);
410	409		inc(Counter);
411	410		// wake A
412	411		RtlEventSetEvent(Form1.ThreadA.WaitForB);
413	412		end;
414	413		end;
415	414		```
416	415
417	416		## Fork
418	417
419	418		When forking in a multithreaded application, be aware that any threads created and running BEFORE the fork (or fpFork) call, will NOT be running in the child process. As stated on the fork() man page, any threads that were running before the fork call, their state will be undefined.
420	419
421	420		So be aware of any threads initializing before the call (including on the initialization section). They will NOT work.
422	421
423	422		## Distributed computing
424	423
425	424		The next higher steps after multi threading is running the treads on multiple machines.
426	425
427	426		- You can use one of the TCP suites like synapse, lnet or indy for communications. This gives you maximum flexibility and is mostly used for loosely connected Client / Server applications.
428	427		- You can use message passing libraries like [[MPICH]], which are used for HPC (High Performance Computing) on clusters.
429	428
430	429		---
431	430		From the Free Pascal wiki, page "Multithreaded Application Tutorial/de", as it stood on 2023-06-23 after a change by Monta, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history