Multithreaded Application Tutorial/de: what changed

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

Old	New		Line
1	1		Zurück zu den [[Additional information/de\|Zusätzlichen Informationen]].\
2	2
3	3		== Überblick ==
4	4
5	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.
6	6
7	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.
8	8
9	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.
10	10
11	11		Andere Anwendungen, bei denen Multithread-Programmierung zum Einsatz kommt, sind Server-Anwendungen, die mehrere Klienten gleichzeitig betreuen müssen.
12	12
13	13		Multithread-Anwendungen ermöglichen auch die Aufteilungen der Lasten einer Berechnung auf mehrere Kerne einer Multi-Core-CPU.
14	14
15	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).
16	16
17	17		## Benötigt Ihre Anwendung wirklich Multithread-Eigenschaften?
18	18
19	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.
20	20
21	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.
22	22
23	23		Multithreading wird wirklich benötigt für:
24	24
25	25		- blocking handles, wie Netzwerkkommunikation, Interrupts (Linux)
26	26		- Mehrprozessor- oder Mehrkernbetrieb
27	27		- Algorithmen und Bibliotheksaufrufe, die nicht in mehrere kleine Stufen zerteilt werden können.
28	28
29	29		## Die Klasse TThread
30	30
31	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".
32	32
33	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.
34	34
35	35		In die (mit Parameter Override) überschriebene Methode Execute schreibt man den vom Thread auszuführenden Quelltext hinein.
36	36
37	37		Die Klasse TThread besitzt die wichtige Eigenschaft (property): Terminated : boolean; (Standardeinstellung: Terminated=false)
38	38
39	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.
40	40
41	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.
42	42
43	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.
44	44
45	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:
46	46
47	47		``` pascal
48	48		Type
49	49		TMyThread = class(TThread)
50	50		private
51	51		fStatusText : string;
52	52		procedure ShowStatus;
53	53		protected
54	54		procedure Execute; override;
55	55		public
56	56		Constructor Create(CreateSuspended : boolean);
57	57		end;
58	58
59	59		constructor TMyThread.Create(CreateSuspended : boolean);
60	60		begin
61	61		FreeOnTerminate := True;
62	62		inherited Create(CreateSuspended);
63	63		end;
64	64
65	65		procedure TMyThread.ShowStatus;
66	66		// Diese Methode wird vom MainThread ausgeführt und kann deshalb auf alle GUI-Elemente zugreifen
67	67		begin
68	68		Form1.Caption := fStatusText;
69	69		end;
70	70
71	71		procedure TMyThread.Execute;
72	72		var
73	73		newStatus : string;
74	74		begin
75	75		fStatusText := 'TMyThread Starting...';
76	76		Synchronize(@Showstatus);
77	77		fStatusText := 'TMyThread Running...';
78	78		while (not Terminated) and ([any condition required]) do
79	79		begin
80	80		...
81	81		// here goes the code of the main thread loop
82	82		...
83	83		if NewStatus <> fStatusText then
84	84		begin
85	85		fStatusText := newStatus;
86	86		Synchronize(@Showstatus);
87	87		end;
88	88		end;
89	89		end;
90	90		```
91	91
92	92		In der Hauptunit erfolgt dann folgender Aufruf
93	93
94	94		``` pascal
95	95		var
96	96		MyThread : TMyThread;
97	97		begin
98	98		MyThread := TMyThread.Create(True); // So startet es nicht automatisch
99	99		...
100	100		// Here the code initialises anything required before the threads starts executing
101	101		...
102	102		MyThread.Resume;
103	103		end;
104	104		```
105	105
106	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:
107	107
108	108		``` pascal
109	109		Type
110	110		TShowStatusEvent = procedure(Status: String) of Object;
111	111
112	112		TMyThread = class(TThread)
113	113		private
114	114		fStatusText : string;
115	115		FOnShowStatus: TShowStatusEvent;
116	116		procedure ShowStatus;
117	117		protected
118	118		procedure Execute; override;
119	119		public
120	120		Constructor Create(CreateSuspended : boolean);
121	121		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
122	122		end;
123	123
124	124		constructor TMyThread.Create(CreateSuspended : boolean);
125	125		begin
126	126		FreeOnTerminate := True;
127	127		inherited Create(CreateSuspended);
128	128		end;
129	129
130	130		procedure TMyThread.ShowStatus;
131	131		// Diese Methode wird vom MainThread ausgeführt und kann deshalb auf alle GUI-Elemente zugreifen
132	132		begin
133	133		if Assigned(FOnShowStatus) then
134	134		begin
135	135		FOnShowStatus(fStatusText);
136	136		end;
137	137		end;
138	138
139	139		procedure TMyThread.Execute;
140	140		var
141	141		newStatus : string;
142	142		begin
143	143		fStatusText := 'TMyThread Starting...';
144	144		Synchronize(@Showstatus);
145	145		fStatusText := 'TMyThread Running...';
146	146		while (not Terminated) and ([any condition required]) do
147	147		begin
148	148		...
149	149		[here goes the code of the main thread loop]
150	150		...
151	151		if NewStatus <> fStatusText then
152	152		begin
153	153		fStatusText := newStatus;
154	154		Synchronize(@Showstatus);
155	155		end;
156	156		end;
157	157		end;
158	158		```
159	159
160	160		Und im Hauptformular
161	161
162	162		``` pascal
163	163		Type
164	164		TForm1 = class(TForm)
165	165		Button1: TButton;
166	166		Label1: TLabel;
167	167		procedure FormCreate(Sender: TObject);
168	168		procedure FormDestroy(Sender: TObject);
169	169		private
170	170		{ private declarations }
171	171		MyThread: TMyThread;
172	172		procedure ShowStatus(Status: string);
173	173		public
174	174		{ public declarations }
175	175		end;
176	176
177	177		procedure TForm1.FormCreate(Sender: TObject);
178	178		begin
179	179		inherited;
180	180		MyThread := TMyThread.Create(true);
181	181		MyThread.OnShowStatus := @ShowStatus;
182	182		end;
183	183
184	184		procedure TForm1.FormDestroy(Sender: TObject);
185	185		begin
186	186		MyThread.Terminate;
187	187		MyThread.Free;
188	188		inherited;
189	189		end;
190	190
191	191		procedure TForm1.Button1Click(Sender: TObject);
192	192		begin
193	193		MyThread.Resume;
194	194		end;
195	195
196	196		procedure TForm1.ShowStatus(Status: string);
197	197		begin
198	198		Label1.Caption := Status;
199	199		end;
200	200		```
201	201
202	202		## Worauf Sie achten sollten
203	203
204	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.
205	205
206	206		Um auf Exceptions im Thread zu prüfen, können Sie folgendermaßen vorgehen:
207	207
208	208		``` pascal
209	209		MyThread := TThread.Create(False);
210	210		if Assigned(MyThread.FatalException) then
211	211		raise MyThread.FatalException;
212	212		```
213	213
214	214		Dieser Code sorgt dafür daß Exceptions, die während der Erzeugung des Threads auftreten, im Main Thread einen Ausnahmefehler auslösen.
215	215
216	216		## Für Multithread-Anwendungen benötigte Units
217	217
218	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)!
219	219
220	220		Daher sollte der Code Ihrer Lazarus-Anwendung etwa so aussehen:
221	221
222	222		``` pascal
223	223		program MyMultiThreadedProgram;
224	224		{$mode objfpc}{$H+}
225	225		uses
226	226		{$ifdef unix}
227	227		cthreads,
228	228		{$endif}
229	229		Interfaces, // dies bindet das LCL Widgetset ein
230	230		Forms
231	231		{ fügen Sie Ihre Units hier hinzu },
232	232		```
233	233
234	234		Wenn Sie dies vergessen, kommt die folgende Fehlermeldung:
235	235
236		-	~~` This binary has no thread support compiled in.`\~~
237		-	~~` Recompile the application with a thread-driver in the program uses clause before other units using thread.`~~
	236	+	``` pascal
	237	+	This binary has no thread support compiled in.
	238	+	Recompile the application with a thread-driver in the program uses clause before other units using thread.
	239	+	```
238	240
239	241		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):
240	242
241	243		``` pascal
242	244		uses
243	245		{$IFDEF UNIX}{$IFDEF UseCThreads}
244	246		cthreads,
245	247		{$ENDIF}{$ENDIF}
246	248		```
247	249
248	250		## SMP (Mehrprozessor) Unterstützung
249	251
250	252		Sobald Sie Threads benutzen, werden diese vom Betriebsystem auf mehrere Prozessoren verteilt.
251	253
252	254		## Debuging Multithread-Anwendungen mit Lazarus
253	255
254	256		Das Debuggen von Multithread-Anwendungen wird von Lazarus zur Zeit noch nicht vollständig unterstützt.
255	257
256	258		### Debugger Ausgabe
257	259
258	260		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.
259	261
260	262		Die Unit LCLProc enthält einige Funktionen, um jeden Thread seine eigene Logdatei schreiben zu lassen:
261	263
262	264		``` pascal
263	265		procedure DbgOutThreadLog(const Msg: string); overload;
264	266		procedure DebuglnThreadLog(const Msg: string); overload;
265	267		procedure DebuglnThreadLog(Args: array of const); overload;
266	268		procedure DebuglnThreadLog; overload;
267	269		```
268	270
269	271		Zum Beispiel: Anstelle von writeln('irgendein Text ', 123); verwenden Sie
270	272
271	273		``` pascal
272	274		DebuglnThreadLog(['irgendein Text ', 123]);
273	275		```
274	276
275	277		Dies wird eine Zeile 'irgendein Text 123' an die Log\<PID\>.txt Datei anhängen, wobei \<PID\> die Prozess ID des aktuellen Threads ist.
276	278
277	279		Es ist eine gute Idee, die Logdateien vor jedem Lauf zu entfernen:
278	280
279	281		``` bash
280	282		rm -f Log* && ./project1
281	283		```
282	284
283	285		### Linux
284	286
285	287		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.
286	288
287	289		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.
288	290
289	291		#### X-Server in einem neuen Terminal starten
290	292
291	293		Starten Sie eine neue X-Instanz. Dies können Sie über die Konsole mit folgendem Befehl erreichen:
292	294
293		-	~~` X :1 &`~~
	295	+	```text
	296	+	X :1 &
	297	+	```
294	298
295	299		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)
296	300
297	301		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:
298	302
299		-	~~` gnome-session --display=:1 &`~~
	303	+	```text
	304	+	gnome-session --display=:1 &
	305	+	```
300	306
301	307		#### X-Server in einem Fenster starten
302	308
303	309		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.
304	310
305	311		Mit dem Befehl
306	312
307		-	~~` Xnest :1 -ac`~~
	313	+	```text
	314	+	Xnest :1 -ac
	315	+	```
308	316
309	317		starten Sie mit Xnest eine X-Sitzung auf :1 und deaktivieren die Zugriffskontrolle.
310	318
311	319		Unter GNOME können Sie auch folgenden Befehl verwenden:
312	320
313		-	~~` gdmflexiserver --xnest`~~
	321	+	```text
	322	+	gdmflexiserver --xnest
	323	+	```
314	324
315	325		Dies startet nicht nur eine X-Sitzung; es wird auch gleichzeitig eine neue GDM-Sitzung, in der Sie sich anmelden können, gestartet.
316	326
317	327		#### Benötigte Einstellungen in Lazarus
318	328
319	329		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.
320	330
321	331		Jetzt wird die Anwendung auf dem zweiten X Server laufen und Sie sind in der Lage, sie vom ersten aus zu debuggen.
322	332
323	333		Dies wurde mit Free Pascal 2.0 und Lazarus 0.9.10 unter Windows und Linux getestet.
324	334
325	335		## Widgetsets
326	336
327	337		Die win32, gtk und carbon Schnittstellen unterstützen Multithreading vollständig. Das bedeutet, TThread, critical sections und Synchronize funktioniert.
328	338
329	339		## Critical sections
330	340
331	341		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.
332	342
333	343		Zur Verwendung von critical sections gehen Sie wie folgt vor:
334	344
335	345		Fügen Sie über uses die Unit SyncObjs hinzu, die die notwendigen Routinen beinhaltet.
336	346
337	347		Als nächsten Schritt deklarieren Sie die critical section (für alle Threads, die auf die section Zugriff haben sollen):
338	348
339	349		``` pascal
340	350		MyCriticalSection: TRTLCriticalSection;
341	351		```
342	352
343	353		Erstellen Sie die Section mit folgender Prozedur:
344	354
345		-	~~` InitCriticalSection(MyCriticalSection);`~~
	355	+	```text
	356	+	InitCriticalSection(MyCriticalSection);
	357	+	```
346	358
347	359		Starten Sie einige Threads, die exklusive Aufgaben durchführen:
348	360
349	361		``` pascal
350	362		EnterCriticalSection(MyCriticalSection);
351	363		try
352	364		// An dieser Stelle können Sie auf Variablen zugreifen, Dateien schreiben, auf das Netzwerk zugreifen, u.s.w.
353	365		finally
354	366		LeaveCriticalSection(MyCriticalSection);
355	367		end;
356	368		```
357	369
358	370		Nachdem alle Threads, die Zugriff auf die critical section hatten, beendet wurden, müssen Sie sie nun deinitialisieren:
359	371
360	372		``` pascal
361	373		DoneCriticalSection(MyCriticalSection);
362	374		```
363	375
364	376		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.
365	377
366	378		Beispiel: 5 Threads, die einen einzigen Zähler erhöhen: lazarus/examples/multithreading/criticalsectionexample1.lpi
367	379
368	380		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.
369	381
370	382		### Gemeinsamer Variablenzugriff
371	383
372	384		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.
373	385
374	386		Als Beispiel: 5 Threads inkrementieren einen Counter: lazarus/examples/multithreading/criticalsectionexample1.lpi
375	387
376	388		## Wenn ein Thread das Ergebnis eines anderen benötigt...
377	389
378	390		Wenn ein Thread A das Ergebnis eines Threads B benötigt, muss er warten, bis B fertig ist.
379	391
380	392		Wichtig: Der Main-Thread sollte niemals auf einen anderen Thread warten müssen. Für diesen Fall benutzen Sie am Besten Synchronize (oben beschrieben).
381	393
382	394		Beispiel: lazarus/examples/multithreading/waitforexample1.lpi
383	395
384	396		``` pascal
385	397		{ TThreadA }
386	398
387	399		procedure TThreadA.Execute;
388	400		begin
389	401		Form1.ThreadB := TThreadB.Create(false);
390	402		// create event
391	403		WaitForB := RTLEventCreate;
392	404		while not Application.Terminated do begin
393	405		// wait infinitely (until B wakes A)
394	406		RtlEventWaitFor(WaitForB);
395	407		WriteLn('A: ThreadB.Counter=', Form1.ThreadB.Counter);
396	408		end;
397	409		end;
398	410
399	411		{ TThreadB }
400	412
401	413		procedure TThreadB.Execute;
402	414		var
403	415		i: Integer;
404	416		begin
405	417		Counter := 0;
406	418		while not Application.Terminated do begin
407	419		// B: Working ...
408	420		Sleep(1500);
409	421		inc(Counter);
410	422		// wake A
411	423		RtlEventSetEvent(Form1.ThreadA.WaitForB);
412	424		end;
413	425		end;
414	426		```
415	427
416	428		## Fork
417	429
418	430		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.
419	431
420	432		So be aware of any threads initializing before the call (including on the initialization section). They will NOT work.
421	433
422	434		## Distributed computing
423	435
424	436		The next higher steps after multi threading is running the treads on multiple machines.
425	437
426	438		- 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.
427	439		- You can use message passing libraries like [[MPICH]], which are used for HPC (High Performance Computing) on clusters.
428	440
429	441		---
430	442		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