Multithreaded Application Tutorial/pl: what changed

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

Old	New		Line
1	1		Kurs tworzenia aplikacji wielowątkowych
2	2
3	3		## Wprowadzenie
4	4
5	5		Na tej stronie spróbujemy wyjaśnić, w jaki sposób napisać i debugować aplikacje wielowątkowe przy pomocy Free Pascala i Lazarusa. Aplikacja wielowątkowa to program, który tworzy dwa lub więcej wątków wykonawczych działających w tym samym czasie. Jeśli nie miałeś dotąd do czynienia z wielowątkowością, przeczytaj akapit „Czy potrzebujesz wielowątkowości?” aby ustalić, czy jest ci to naprawdę potrzebne, bo być może zaoszczędzisz sobie bólu głowy.
6	6
7	7		Pierwszy wątek nazywany jest głównym wątkiem. Główny wątek to ten, który jest tworzony przez System Operacyjny, to ten sam, w którym nasza aplikacja rozpoczyna działanie. Główny wątek musi być jedynym wątkiem, który aktualizuje komponenty do komunikacji z użytkownikiem: w przeciwnym wypadku, aplikacja może się zawiesić.
8	8
9	9		Podstawowym założeniem jest to, aby aplikacja mogła przetwarzać pewne dane w tle, tj. w drugim wątku, podczas gdy użytkownik może kontynuować pracę przy użyciu głównego wątku.
10	10
11	11		Innym zastosowaniem wątków jest po prostu możliwość lepszej reakcji programu. Jeśli tworzysz dużą aplikację lub gdy użytkownik naciśnie przycisk aplikacji rozpoczynając jakiś duży proces ... dopóki trwa przetwarzanie, ekran przestaje odpowiadać, co powoduje błędne lub mylące wrażenie, że aplikacja jest zawieszona. Jeśli duży proces przebiega w drugim wątku, aplikacja zachowuje się (prawie) tak, jakby była w stanie bezczynności. W tym przypadku dobrym pomysłem jest aby, przed rozpoczęciem wątku, wyłączyć odpowiednie przyciski na formularzu, w celu uniknięcia ponownego uruchomienia drugiego wątku przez użytkownika.
12	12
13	13		Jeszcze innym zastosowaniem wielowątkowości może być serwer, który jest w stanie dać odpowiedź wielu klientom, w tym samym czasie.
14	14
15	15		## Czy potrzebujesz wielowątkowości?
16	16
17	17		Jeśli dopiero poznajesz wielowątkowość i chciałbyś tylko stworzyć aplikację z szybszym czasem reakcji w chwili gdy wykonuje ona umiarkowanie długotrwałe zadanie, wówczas wielowątkowość może być nadmiarowa w stosunku do wymagań. Aplikacje wielowątkowe są zawsze trudniejsze do debugowania i często są znacznie bardziej skomplikowane, jednak w wielu przypadkach wcale nie potrzebujesz używać wielowątkowości. Jeden wątek jest wystarczający. Możesz podzielić czasochłonne zadanie na kilka mniejszych części, oraz użyć procedurę Application.ProcessMessages. Procedura ta pozwala bibliotece LCL obsłużyć wszystkie oczekujące komunikaty i powrócić do miejsca jej wywołania. Główną ideą jest to, aby wywoływać Application.ProcessMessages w regularnych odstępach czasu w trakcie wykonywania długotrwałego zadania, np. po to aby sprawdzić, czy użytkownik kliknął na jakąś kontrolkę lub czy wskaźnik postępu musi zostać przemalowany albo zdarzyło się jeszcze coś innego.
18	18
19	19		Przykład: Czytanie dużego pliku i jego przetwarzanie. Zobacz: examples/multithreading/singlethreadingexample1.lpi.
20	20
21	21		Wielowątkowość jest potrzebna tylko w przypadku
22	22
23	23		- używania uchwytów blokujących, takich jak w komunikacji sieci
24	24		- korzystania z wielu procesorów jednocześnie (SMP)
25	25		- algorytmów i bibliotek, które muszą być wywoływane przez API i jako takie nie mogą być podzielone na mniejsze części.
26	26
27	27		Jeśli chcesz użyć wielowątkowości, aby zwiększyć prędkość przy użyciu wielu procesorów jednocześnie, sprawdź, czy twój obecny program w tej chwili wykorzystuje 100% zasobów 1 rdzenia CPU (na przykład, program może aktywnie korzystać z operacji wejścia-wyjścia, jak zapis do pliku i to zajmuje dużo czasu, ale nie obciąża procesora, i w tym przypadku program nie będzie działał szybciej z wieloma wątkami). Należy również sprawdzić, czy poziom optymalizacji jest ustawiony na maksymalny (3). Przełączając poziom optymalizacji z 1 na 3, program może stać się około 5 razy szybszy.
28	28
29	29		## Moduły potrzebne do tworzenia aplikacji wielowątkowej
30	30
31	31		Nie potrzebujesz żadnych specjalnych modułów do tego, aby pracować z systemem Windows. Jednak w przypadku Linuksa, Mac OS X i FreeBSD, należy użyć modułu cthreads i musi być on użyty jako pierwszy moduł projektu (program źródłowy, zwykle znajdujący się w pliku .lpr)!
32	32
33	33		Dlatego twój kod aplikacji Lazarusa powinien wyglądać tak:
34	34
35	35		``` pascal
36	36		program MyMultiThreadedProgram;
37	37		{$mode objfpc}{$H+}
38	38		uses
39	39		{$ifdef unix}
40	40		cthreads,
41	41		cmem, // menedżer pamięci c jest w niektórych systemach znacznie szybszy dla aplikacji wielowątkowych
42	42		{$endif}
43	43		Interfaces, // to zawiera widżety LCL
44	44		Forms
45	45		{ tu możesz dodać następne moduły },
46	46		```
47	47
48	48		Jeśli o tym zapomnisz i użyjesz TThread, otrzymasz następujący błąd podczas uruchamiania:
49	49
50		-	~~` This binary has no thread support compiled in.`\~~
51		-	~~` Recompile the application with a thread-driver in the program uses clause before other units using thread.`~~
	50	+	``` pascal
	51	+	This binary has no thread support compiled in.
	52	+	Recompile the application with a thread-driver in the program uses clause before other units using thread.
	53	+	```
52	54
53	55		> Note: Jeśli pojawi się błąd linkera o tym, że nie znaleziono „mcount” to znaczy, że używasz jakiegoś modułu, który zawiera kod wielowątkowy i musisz dodać moduł cthreads lub użyć [[smart linking\|sprytnego łączenia]].
54	56
55	57		> Note: Jeśli w procedurze SYSTEM_NOTHREADERROR otrzymasz błąd: „Project raised exception class 'RunError(232)'” to znaczy, że twój kod potrzebuje wątków i musisz dodać moduł cthreads.
56	58
57	59		## Przykład w czystym FPC
58	60
59	61		Poniższy kod przedstawia bardzo prosty przykład. Testowany z FPC 3.0.4 na Win7.
60	62
61	63		``` pascal
62	64		Program ThreadTest;
63	65		{ przetestuj możliwość aplikacji wielowątkowej }
64	66		{
65	67		OUTPUT
66	68		wątek 1 uruchomiony
67	69		wątek 1 zmienna thri 0 Długość(s)= 1
68	70		wątek 1 zmienna thri 1 Długość(s)= 2
69	71		wątek 1 zmienna thri 2 Długość(s)= 3
70	72		wątek 1 zmienna thri 3 Długość(s)= 4
71	73		wątek 1 zmienna thri 4 Długość(s)= 5
72	74		wątek 1 zmienna thri 5 Długość(s)= 6
73	75		wątek 1 zmienna thri 6 Długość(s)= 7
74	76		wątek 1 zmienna thri 7 Długość(s)= 8
75	77		wątek 1 zmienna thri 8 Długość(s)= 9
76	78		wątek 1 zmienna thri 9 Długość(s)= 10
77	79		wątek 1 zmienna thri 10 Długość(s)= 11
78	80		wątek 1 zmienna thri 11 Długość(s)= 12
79	81		wątek 1 zmienna thri 12 Długość(s)= 13
80	82		wątek 1 zmienna thri 13 Długość(s)= 14
81	83		wątek 1 zmienna thri 14 Długość(s)= 15
82	84		wątek 2 uruchomiony
83	85		wątek 3 uruchomiony
84	86		wątek 1 zmienna thri 15 Długość(s)= 16
85	87		wątek 2 zmienna thri 0 Długość(s)= 1
86	88		wątek 3 zmienna thri 0 Długość(s)= 1
87	89		wątek 1 zmienna thri 16 Długość(s)= 17
88	90		...
89	91		...
90	92		wątek 5 zmienna thri 997 Długość(s)= 998
91	93		wątek 5 zmienna thri 998 Długość(s)= 999
92	94		wątek 5 zmienna thri 999 Długość(s)= 1000
93	95		wątek 5 zakończony
94	96		wątek 10 zmienna thri 828 Długość(s)= 829
95	97		wątek 9 zmienna thri 675 Długość(s)= 676
96	98		wątek 4 zmienna thri 656 Długość(s)= 657
97	99		wątek 10 zmienna thri 829 Długość(s)= 830
98	100		wątek 9 zmienna thri 676 Długość(s)= 677
99	101		wątek 9 zmienna thri 677 Długość(s)= 678
100	102		wątek 10 zmienna thri 830 Długość(s)= 831
101	103		wątek 10 zmienna thri 831 Długość(s)= 832
102	104		wątek 10 zmienna thri 832 Długość(s)= 833
103	105		wątek 10 zmienna thri 833 Długość(s)= 834
104	106		wątek 10 zmienna thri 834 Długość(s)= 835
105	107		wątek 10 zmienna thri 835 Długość(s)= 836
106	108		wątek 10 zmienna thri 836 Długość(s)= 837
107	109		wątek 10 zmienna thri 837 Długość(s)= 838
108	110		wątek 10 zmienna thri 838 Długość(s)= 839
109	111		wątek 10 zmienna thri 839 Długość(s)= 840
110	112		wątek 9 zmienna thri 678 Długość(s)= 679
111	113		...
112	114		...
113	115		wątek 4 zmienna thri 994 Długość(s)= 995
114	116		wątek 4 zmienna thri 995 Długość(s)= 996
115	117		wątek 4 zmienna thri 996 Długość(s)= 997
116	118		wątek 4 zmienna thri 997 Długość(s)= 998
117	119		wątek 4 zmienna thri 998 Długość(s)= 999
118	120		wątek 4 zmienna thri 999 Długość(s)= 1000
119	121		wątek 4 zakończony
120	122		10
121	123
122	124		}
123	125
124	126		uses
125	127		{$ifdef unix}cthreads, {$endif} sysutils;
126	128
127	129		const
128	130		threadcount = 10;
129	131		stringlen = 1000;
130	132
131	133		var
132	134		finished : longint;
133	135
134	136		threadvar
135	137		thri : ptrint;
136	138
137	139		function f(p : pointer) : ptrint;
138	140		var
139	141		s : ansistring;
140	142		begin
141	143		Writeln('wątek ',longint(p),' uruchomiony');
142	144		thri:=0;
143	145		while (thri<stringlen) do begin
144	146		s:=s+'1'; { stwórz opóźnienie }
145	147		writeln('wątek ',longint(p),' zmienna thri ',thri,' Długość(s)= ',length(s));
146	148		inc(thri);
147	149		end;
148	150		Writeln('wątek ',longint(p),' zakończony');
149	151		InterLockedIncrement(finished);
150	152		f:=0;
151	153		end;
152	154
153	155		var
154	156		i : longint;
155	157
156	158		Begin
157	159		finished:=0;
158	160		for i:=1 to threadcount do
159	161		BeginThread(@f,pointer(i));
160	162		while finished<threadcount do ;
161	163		Writeln(finished);
162	164		End.
163	165		```
164	166
165	167		## Klasa TThread
166	168
167	169		Poniższy przykład można znaleźć w katalogu examples/multithreading/.
168	170
169	171		Aby utworzyć aplikację wielowątkową, najłatwiej jest użyć klasy TThread. Ta klasa pozwala w prosty sposób stworzyć dodatkowy wątek (obok głównego wątku). Zwykle wymagane jest przesłonięcie tylko dwóch metod: konstruktora Create i metody Execute.
170	172
171	173		W konstruktorze przygotujesz wątek do uruchomienia. Ustawisz początkowe wartości dla zmiennych lub właściwości, których potrzebujesz. Oryginalny konstruktor TThread wymaga parametru o nazwie Suspended. Jak można się spodziewać, ustawienie Suspended = True zapobiegnie automatycznemu uruchomieniu wątku po utworzeniu. Jeśli Suspended = False, wątek zacznie działać zaraz po utworzeniu. Jeśli wątek zostanie utworzony jako zawieszony, zostanie uruchomiony dopiero po wywołaniu metody Start.
172	174
173	175		> Note: Metoda Resume jest [przestarzała od FPC 2.4.4](http://wiki.freepascal.org/User_Changes_2.4.4#TThread.Suspend_and_TThread.Resume_have_been_deprecated). Została zastąpiona przez metodę Start.
174	176
175	177		Począwszy od wersji FPC 2.0.1 i nowszych, TThread.Create ma również niejawny parametr dla rozmiaru stosu. W razie potrzeby możesz teraz zmienić domyślny rozmiar stosu każdego utworzonego wątku. Dobrym przykładem są głębokie rekurencje wywołań procedur w wątku. Jeśli nie określisz parametru rozmiaru stosu, zostanie użyty domyślny rozmiar stosu systemu operacyjnego.
176	178
177	179		W zastąpionej metodzie Execute napisz kod, który będzie uruchamiany w wątku.
178	180
179	181		Klasa TThread ma jedną ważną właściwość: Terminated : boolean;
180	182
181	183		Jeśli wątek ma pętlę (i jest to typowe), pętla powinna zostać zakończona, gdy Terminated ma wartość true (domyślnie jest to false). W każdym przebiegu należy sprawdzić wartość Terminated, a jeśli jest prawdziwa, pętla powinna zostać zakończona tak szybko, jak to konieczne, po każdym koniecznym czyszczeniu. ~~Należy pamiętać, że metoda Terminate domyślnie nic nie robi: metoda .Execute musi jawnie zaimplementować obsługę, aby zakończyć swoje zadanie.~~ Metoda Terminate domyślnie ustawia jedynie właściwość Terminated na wartość True.
182	184
183	185		Jak wyjaśniliśmy wcześniej, wątek nie powinien wchodzić w interakcje z widocznymi komponentami. Aktualizacje widocznych komponentów muszą być dokonywane w kontekście głównego wątku.
184	186
185	187		Aby to zrobić, istnieje metoda TThread o nazwie Synchronize. Synchronize wymaga metody w wątku (która nie przyjmuje parametrów) jako argumentu. Po wywołaniu tej metody za pomocą Synchronize(@MyMethod) wykonanie wątku zostanie wstrzymane, kod MyMethod zostanie wywołany z głównego wątku, a następnie zostanie wznowione wykonywanie wątku.
186	188
187	189		Dokładne działanie metody Synchronize zależy od platformy, ale zasadniczo wykonuje ona:
188	190
189	191		- wysyła wiadomość do głównej kolejki wiadomości i zasypia
190	192		- ostatecznie główny wątek przetwarza wiadomość i wywołuje MyMethod. W ten sposób MyMethod jest wywoływana bez kontekstu, co oznacza, że nie wykonuje się podczas zdarzenia wciśnięcia myszy lub podczas malowania, ale po.
191	193		- po wykonaniu przez główny wątek MyMethod, budzi ona uśpiony wątek i przetwarza następną wiadomość
192	194		- następnie wątek jest kontynuowany.
193	195
194	196		Jest jeszcze jedna ważna właściwość TThread: FreeOnTerminate. Jeśli ta właściwość ma wartość true, obiekt wątku jest automatycznie zwalniany po zatrzymaniu wykonywania wątku (metoda .Execute). W przeciwnym razie aplikacja będzie musiała zwolnić ją ręcznie.
195	197
196	198		Przykład:
197	199
198	200		``` pascal
199	201		Type
200	202		TMyThread = class(TThread)
201	203		private
202	204		fStatusText : string;
203	205		procedure ShowStatus;
204	206		protected
205	207		procedure Execute; override;
206	208		public
207	209		Constructor Create(CreateSuspended : boolean);
208	210		end;
209	211		constructor TMyThread.Create(CreateSuspended : boolean);
210	212		begin
211	213		inherited Create(CreateSuspended);
212	214		FreeOnTerminate := True;
213	215		end;
214	216
215	217		procedure TMyThread.ShowStatus;
216	218		// ta metoda jest wykonywana przez główny wątek i dlatego może uzyskać dostęp do wszystkich elementów GUI.
217	219		begin
218	220		Form1.Caption := fStatusText;
219	221		end;
220	222
221	223		procedure TMyThread.Execute;
222	224		var
223	225		newStatus : string;
224	226		begin
225	227		fStatusText := 'TMyThread Starting...';
226	228		Synchronize(@Showstatus);
227	229		fStatusText := 'TMyThread Running...';
228	230		while (not Terminated) and ([inne wymagane warunki]) do
229	231		begin
230	232		...
231	233		[tutaj jest kod głównej pętli wątku]
232	234		...
233	235		if NewStatus <> fStatusText then
234	236		begin
235	237		fStatusText := newStatus;
236	238		Synchronize(@Showstatus);
237	239		end;
238	240		end;
239	241		end;
240	242		```
241	243
242	244		W aplikacji:
243	245
244	246		``` pascal
245	247		var
246	248		MyThread : TMyThread;
247	249		begin
248	250		MyThread := TMyThread.Create(True); // W ten sposób nie uruchamia się automatycznie
249	251		...
250	252		[Tutaj kod inicjuje wszystko, co jest wymagane, zanim wątki zaczną się wykonywać]
251	253		...
252	254		MyThread.Start;
253	255		end;
254	256		```
255	257
256	258		Jeśli chcesz, aby Twoja aplikacja była bardziej elastyczna, możesz utworzyć zdarzenie dla wątku; w ten sposób Twoja zsynchronizowana metoda nie będzie ściśle powiązana z określoną formą lub klasą: możesz dołączyć detektory do zdarzenia wątku. Oto przykład:
257	259
258	260		``` pascal
259	261		Type
260	262		TShowStatusEvent = procedure(Status: String) of Object;
261	263
262	264		TMyThread = class(TThread)
263	265		private
264	266		fStatusText : string;
265	267		FOnShowStatus: TShowStatusEvent;
266	268		procedure ShowStatus;
267	269		protected
268	270		procedure Execute; override;
269	271		public
270	272		Constructor Create(CreateSuspended : boolean);
271	273		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
272	274		end;
273	275
274	276		constructor TMyThread.Create(CreateSuspended : boolean);
275	277		begin
276	278		inherited Create(CreateSuspended);
277	279		FreeOnTerminate := True;
278	280		end;
279	281
280	282		procedure TMyThread.ShowStatus;
281	283		// ta metoda jest wykonywana przez główny wątek i dlatego może uzyskać dostęp do wszystkich elementów GUI.
282	284		begin
283	285		if Assigned(FOnShowStatus) then
284	286		begin
285	287		FOnShowStatus(fStatusText);
286	288		end;
287	289		end;
288	290
289	291		procedure TMyThread.Execute;
290	292		var
291	293		newStatus : string;
292	294		begin
293	295		fStatusText := 'TMyThread Starting...';
294	296		Synchronize(@Showstatus);
295	297		fStatusText := 'TMyThread Running...';
296	298		while (not Terminated) and ([inne wymagane warunki]) do
297	299		begin
298	300		...
299	301		[tutaj jest kod głównej pętli wątku]
300	302		...
301	303		if NewStatus <> fStatusText then
302	304		begin
303	305		fStatusText := newStatus;
304	306		Synchronize(@Showstatus);
305	307		end;
306	308		end;
307	309		end;
308	310		```
309	311
310	312		W aplikacji:
311	313
312	314		``` pascal
313	315		Type
314	316		TForm1 = class(TForm)
315	317		Button1: TButton;
316	318		Label1: TLabel;
317	319		procedure Button1Click(Sender: TObject);
318	320		procedure FormCreate(Sender: TObject);
319	321		procedure FormDestroy(Sender: TObject);
320	322		private
321	323		{ private declarations }
322	324		MyThread: TMyThread;
323	325		procedure ShowStatus(Status: string);
324	326		public
325	327		{ public declarations }
326	328		end;
327	329
328	330		procedure TForm1.FormCreate(Sender: TObject);
329	331		begin
330	332		inherited;
331	333		MyThread := TMyThread.Create(true);
332	334		MyThread.OnShowStatus := @ShowStatus;
333	335		end;
334	336
335	337		procedure TForm1.FormDestroy(Sender: TObject);
336	338		begin
337	339		MyThread.Terminate;
338	340
339	341		// FreeOnTerminate ma wartość true więc nie powinniśmy pisać:
340	342		// MyThread.Free;
341	343		inherited;
342	344		end;
343	345
344	346		procedure TForm1.Button1Click(Sender: TObject);
345	347		begin
346	348		MyThread.Start;
347	349		end;
348	350
349	351		procedure TForm1.ShowStatus(Status: string);
350	352		begin
351	353		Label1.Caption := Status;
352	354		end;
353	355		```
354	356
355	357		## Ważne rzeczy, na które trzeba zwrócić uwagę
356	358
357	359		### Kontrola stosu w systemie Windows
358	360
359	361		Może wystąpić potencjalny problem w systemie Windows, jeśli używasz przełącznika -Ct (sprawdzanie stosu). Z powodów, które nie są do końca jasne, sprawdzanie stosu będzie „wyzwalane” z każdym wywołaniem TThread.Create, jeśli używasz domyślnego rozmiaru stosu. W tej chwili jedynym rozwiązaniem jest po prostu nieużywanie przełącznika -Ct. Zauważ, że NIE powoduje to wyjątku w głównym wątku, ale w nowo utworzonym. To „wygląda” tak, jakby wątek nigdy nie został uruchomiony.
360	362
361	363		Poprawny kod do sprawdzenia tego i innych wyjątków, które mogą wystąpić podczas tworzenia wątków, to:
362	364
363	365		``` pascal
364	366		MyThread := TThread.Create(False);
365	367
366	368		if Assigned(MyThread.FatalException) then
367	369		raise MyThread.FatalException;
368	370		```
369	371
370	372		Ten kod zapewni, że każdy wyjątek, który wystąpił podczas tworzenia wątku, zostanie zgłoszony w głównym wątku.
371	373
372	374		### Wielowątkowość w pakietach
373	375
374	376		Pakiety korzystające z wielowątkowości powinny dodawać flagę -dUseCThreads do dodatkowo używanych opcji. Otwórz edytor pakietów, a następnie Opcje \> Użycie \> Dodatkowe i dodaj -dUseCThreads. Spowoduje to zdefiniowanie tej flagi dla wszystkich projektów i pakietów korzystających z tego pakietu, w tym IDE. IDE i wszystkie nowe aplikacje utworzone przez IDE mają już następujący kod w swoim pliku .lpr:
375	377
376	378		``` pascal
377	379		uses
378	380		{$IFDEF UNIX}{$IFDEF UseCThreads}
379	381		cthreads,
380	382		cmem, // Menedżer pamięci c jest w niektórych systemach znacznie szybszy w przypadku wielowątkowości
381	383		{$ENDIF}{$ENDIF}
382	384		```
383	385
384	386		### Moduł Heaptrc
385	387
386	388		Nie można używać przełącznika -gh z modułem cmem. Przełącznik -gh używa modułu heaptrc, który rozszerza menedżer stosu. Dlatego moduł heaptrc musi być używany po module cmem.
387	389
388	390		``` pascal
389	391		uses
390	392		{$IFDEF UNIX}{$IFDEF UseCThreads}
391	393		cthreads,
392	394		cmem, // Menedżer pamięci c jest w niektórych systemach znacznie szybszy w przypadku wielowątkowości
393	395		{$ENDIF}{$ENDIF}
394	396		heaptrc,
395	397		```
396	398
397	399		### Initialization and Finalization
398	400
399	401		Aby zainicjować sam obiekt wątku, możesz uruchomić go w trybie zawieszenia i ustawić jego właściwości i/lub utworzyć nowy konstruktor i wywołać odziedziczony konstruktor.
400	402
401	403		Uwaga: Używanie AfterConstruction, gdy CreateSuspended=false jest niebezpieczne, ponieważ wątek już zaczął działać.
402	404
403	405		Z drugiej strony, destruktor może służyć do finalizowania zasobów obiektu.
404	406
405	407		``` pascal
406	408		type
407	409		TMyThread = class(TThread)
408	410		private
409	411		fRTLEvent: PRTLEvent;
410	412		public
411	413		procedure Create(SomeData: TSomeObject); override;
412	414		destructor Destroy; override;
413	415		end;
414	416
415	417		procedure TMyThread.Create(SomeData: TSomeObject; CreateSuspended: boolean);
416	418		begin
417	419		// przykład: skonfiguruj zdarzenia, sekcje krytyczne i inne zasoby, takie jak pliki lub połączenia z bazami danych
418	420		RTLEventCreate(fRTLEvent);
419	421		inherited Create(CreateSuspended);
420	422		end;
421	423
422	424		destructor TMyThread.Destroy;
423	425		begin
424	426		RTLeventDestroy(fRTLEvent);
425	427		inherited Destroy;
426	428		end;
427	429		```
428	430
429	431		### Program bez LCL
430	432
431	433		TThread.Synchronize wymaga, aby główny wątek regularnie wywoływał CheckSynchronize. LCL robi to w swojej pętli. Jeśli nie używasz pętli zdarzeń LCL, musisz ją wywołać samodzielnie.
432	434
433	435		## Wsparcie dla SMP
434	436
435	437		Dobrą wiadomością jest to, że jeśli Twoja aplikacja działa poprawnie wielowątkowo, to w ten sposób, jest już włączona obsługa SMP, czyli przetwarzanie wątków przez wiele procesorów!
436	438
437	439		## Debugowanie aplikacji wielowątkowych w Lazarusie
438	440
439	441		Debugowanie na Lazarusie wymaga [[GDB/pl\|GDB]] i szybko staje się coraz bardziej funkcjonalne i stabilne. Jednak nadal istnieje kilka dystrybucji Linuksa z pewnymi problemami.
440	442
441	443		### Wyjście debuggera
442	444
443	445		W jednowątkowej aplikacji możesz po prostu pisać do konsoli/terminala/gdziekolwiek, a kolejność wierszy jest taka sama, jak zostały one napisane. W aplikacjach wielowątkowych sprawy są bardziej skomplikowane. Jeśli dwa wątki piszą, w taki sposób, że jakiś wiersz jest zapisywany przez wątek A przed wierszem przez wątek B, to wiersze niekoniecznie są zapisywane w tej kolejności. Może się nawet zdarzyć, że wątek zapisuje swoje wyjście, w tym samy czasie gdy drugi wątek zapisuje linię. W tej sytuacji pod Linuksem (być może) otrzymasz poprawne wyjście DebugLn(), a pod win32 możesz otrzymać wyjątek (prawdopodobnie DiskFull) z powodu użycia DebugLn() poza głównym wątkiem. Tak więc, aby uniknąć bólów głowy, użyj DebugLnThreadLog() wspomnianego poniżej.
444	446
445	447		Moduł LCLProc zawiera kilka funkcji, które pozwalają każdemu wątkowi zapisywać do własnego pliku dziennika:
446	448
447	449		``` pascal
448	450		procedure DbgOutThreadLog(const Msg: string); overload;
449	451		procedure DebuglnThreadLog(const Msg: string); overload;
450	452		procedure DebuglnThreadLog(Args: array of const); overload;
451	453		procedure DebuglnThreadLog; overload;
452	454		```
453	455
454	456		Na przykład: Zamiast writeln('Jakiś tekst', 123); użyj
455	457
456		-	~~` DebuglnThreadLog(['Jakiś tekst ',123]);`~~
	458	+	```text
	459	+	DebuglnThreadLog(['Jakiś tekst ',123]);
	460	+	```
457	461
458	462		Spowoduje to dodanie linii 'Jakiś tekst 123' do Log\<PID\>.txt, gdzie \<PID\> jest identyfikatorem procesu bieżącego wątku.
459	463
460	464		Dobrym pomysłem jest usunięcie plików dziennika przed każdym uruchomieniem:
461	465
462		-	~~` rm -f Log* && ./project1`~~
	466	+	```text
	467	+	rm -f Log* && ./project1
	468	+	```
463	469
464	470		### Linux
465	471
466	472		Jeśli spróbujesz debugować aplikację wielowątkową w systemie Linux, będziesz miał jeden duży problem: Menedżer pulpitu na serwerze X może się zawiesić. Dzieje się tak na przykład, gdy aplikacja przechwyciła mysz/klawiaturę i została zatrzymana przez gdb, a serwer X czeka na twoją aplikację. Kiedy tak się stanie, możesz po prostu zalogować się z innego komputera i zabić gdb lub wyjść z tej sesji, naciskając CTRL+ALT+F3 i zabić gdb. Alternatywnie możesz ponownie uruchomić menedżera okien: wpisz sudo /etc/init.d/gdm restart. Spowoduje to ponowne uruchomienie menedżera pulpitu i powrót do pulpitu.
467	473
468	474		Ponieważ zależy to od tego, gdzie gdb zatrzymuje twój program, w niektórych przypadkach mogą pomóc pewne sztuczki: dla Ubuntu x64 ustaw opcje projektu do debugowania wymaganego dodatkowego pliku informacyjnego...
469	475
470		-	~~` Projekt -> Opcje projektu -> Opcje kompilatora -> Odpluskwianie, i zaznacz: Use external gdb debug symbols file (-Xg).`~~
	476	+	```text
	477	+	Projekt -> Opcje projektu -> Opcje kompilatora -> Odpluskwianie, i zaznacz: Use external gdb debug symbols file (-Xg).
	478	+	```
471	479
472	480		Inną opcją jest otwarcie innego pulpitu X, uruchomienie IDE/gdb na jednym i aplikacji na drugim, tak aby zawieszał się tylko pulpit testowy. Utwórz nową instancję X za pomocą:
473	481
474		-	~~` X :1 &`~~
	482	+	```text
	483	+	X :1 &
	484	+	```
475	485
476	486		Gdy pulpit się otworzy, możesz przełączyć się na inny pulpit (ten, z którym pracujesz, naciskając CTRL + ALT + F7), będziesz mógł wrócić do nowego pulpitu graficznego za pomocą CTRL + ALT + F8 (jeśli ta kombinacja nie działa, spróbuj z CTRL + ALT + F2 ... ta kombinacja klawiszy działała w [Slackware](http://www.slackware.com)).
477	487
478	488		Następnie możesz, jeśli chcesz, utworzyć sesję pulpitu na X, za pomocą polecenia:
479	489
480		-	~~` gnome-session --display=:1 &`~~
	490	+	```text
	491	+	gnome-session --display=:1 &
	492	+	```
481	493
482	494		Następnie w Lazarusie w oknie dialogowym parametrów uruchamiania projektu (Uruchom -\> Uruchom z parametrami -\> Ekran) zaznacz opcję „Użyj ekranu” i wpisz :1.
483	495
484	496		Teraz aplikacja będzie działać na drugim serwerze X i będziesz mógł ją debugować na pierwszym.
485	497
486	498		Zostało to przetestowane z Free Pascal 2.0 i Lazarus 0.9.10 w systemie Linux.
487	499
488	500		------------------------------------------------------------------------
489	501
490	502		Zamiast tworzyć nową sesję X, można użyć Xnest. Xnest to sesja X w oknie. Korzystanie z niego sprawia, że X serwer nie blokuje się podczas debugowania wątków i jest znacznie łatwiej debugować bez konieczności zmiany terminali.
491	503
492	504		Linia poleceń do uruchomienia Xnest to
493	505
494		-	~~` Xnest :1 -ac`~~
	506	+	```text
	507	+	Xnest :1 -ac
	508	+	```
495	509
496	510		tworzy sesję X na :1 i wyłącza kontrolę dostępu.
497	511
498	512		## Interfejsy widżetów Lazarusa
499	513
500	514		Win32, gtk i interfejsy carbon obsługują wielowątkowość. Oznacza to, że działają tu TThread, krytyczne sekcje i Synchronize. Ale nie są bezpieczne wątkowo. To znaczy, że tylko jeden wątek na raz może uzyskać dostęp do LCL. Ponieważ główny wątek nigdy nie powinien czekać na kolejny wątek, to sprawia, że tylko wątek główny może uzyskać dostęp do LCL, czyli do wszystkiego, co ma związek z uchwytami TControl, Application i widgetów LCL. W LCL jest kilka funkcji bezpiecznych dla wątków. Na przykład większość funkcji w module FileUtil jest bezpieczna wątkowo.
501	515
502	516		### Użycie SendMessage/PostMessage do komunikacji pomiędzy wątkami
503	517
504	518		Tylko jeden wątek w aplikacji powinien wywoływać interfejsy API LCL, zwykle wątek główny. Inne wątki mogą korzystać z LCL za pomocą wielu metod pośrednich, jedną z dobrych opcji jest użycie SendMessage lub PostMessage. LCLIntf.SendMessage i LCLIntf.PostMessage wyślą wiadomość skierowaną do okna w puli wiadomości aplikacji.
505	519
506	520		Zobacz także dokumentację tych procedur:
507	521
508	522		- [[doc:lcl/lclintf/sendmessage.html\|SendMessage]]
509	523		- [[doc:lcl/lclintf/postmessage.html\|PostMessage]]
510	524
511	525		Różnica między SendMessage i PostMessage polega na sposobie, w jaki zwracają kontrolę do wątku wywołującego. Podobnie jak dla Synchronize, w SendMessage bloki i kontrola nie są zwracane, dopóki okno, do którego wiadomość została wysłana, nie skończy jej przetwarzać; jednak w pewnych okolicznościach SendMessage może próbować zoptymalizować przetwarzanie, pozostając w kontekście wątku, który go wywołał. Dzięki PostMessage kontrola jest zwracana natychmiast do określonej przez system maksymalnej liczby umieszczonych w kolejce wiadomości i tak długo, jak na stercie pozostaje miejsce na dołączane dane.
512	526
513	527		W obu przypadkach procedura obsługująca komunikat (patrz niżej) powinna unikać wywoływania application.ProcessMessages, ponieważ może to spowodować wysłanie drugiego komunikatu, który zostanie obsłużony ponownie. Jeśli jest to nieuniknione, prawdopodobnie lepiej byłoby użyć innego mechanizmu do przesyłania serializowanych zdarzeń między wątkami.
514	528
515	529		Oto przykład, w jaki wątek dodatkowy może wysłać tekst, który ma być wyświetlany w kontrolce LCL do wątku głównego:
516	530
517	531		``` pascal
518	532		const
519	533		WM_GOT_ERROR = LM_USER + 2004;
520	534		WM_VERBOSE = LM_USER + 2005;
521	535
522	536		procedure VerboseLog(Msg: string);
523	537		var
524	538		PError: PChar;
525	539		begin
526	540		if MessageHandler = 0 then Exit;
527	541		PError := StrAlloc(Length(Msg)+1);
528	542		StrCopy(PError, PChar(Msg));
529	543		PostMessage(formConsole.Handle, WM_VERBOSE, Integer(PError), 0);
530	544		end;
531	545		```
532	546
533	547		I przykład, jak obsłużyć tę wiadomość z okna:
534	548
535	549		``` pascal
536	550		const
537	551		WM_GOT_ERROR = LM_USER + 2004;
538	552		WM_VERBOSE = LM_USER + 2005;
539	553
540	554		type
541	555		{ TformConsole }
542	556
543	557		TformConsole = class(TForm)
544	558		DebugList: TListView;
545	559		// ...
546	560		private
547	561		procedure HandleDebug(var Msg: TLMessage); message WM_VERBOSE;
548	562		end;
549	563
550	564		var
551	565		formConsole: TformConsole;
552	566
553	567		implementation
554	568
555	569		....
556	570
557	571		{ TformConsole }
558	572
559	573		procedure TformConsole.HandleDebug(var Msg: TLMessage);
560	574		var
561	575		Item: TListItem;
562	576		MsgStr: PChar;
563	577		MsgPasStr: string;
564	578		begin
565	579		MsgStr := PChar(Msg.wparam);
566	580		MsgPasStr := StrPas(MsgStr);
567	581		Item := DebugList.Items.Add;
568	582		Item.Caption := TimeToStr(SysUtils.Now);
569	583		Item.SubItems.Add(MsgPasStr);
570	584		Item.MakeVisible(False);
571	585
572	586		// Po którym następuje coś takiego
573	587
574	588		TrayControl.SetError(MsgPasStr);
575	589		StrDispose(MsgStr)
576	590		end;
577	591
578	592		end.
579	593		```
580	594
581	595		## Sekcje krytyczne
582	596
583	597		Sekcja krytyczna to obiekt służący do upewnienia się, że jakaś część kodu jest wykonywana tylko przez jeden wątek na raz. Sekcja krytyczna musi zostać utworzona/zainicjowana, zanim będzie można jej użyć i zwolniona, gdy nie będzie już potrzebna.
584	598
585	599		Sekcje krytyczne zwykle są używane w ten sposób:
586	600
587	601		Deklaracja sekcji (globalnie dla wszystkich wątków, które powinny mieć dostęp do tej sekcji):
588	602
589		-	~~` MyCriticalSection: TRTLCriticalSection;`~~
	603	+	```text
	604	+	MyCriticalSection: TRTLCriticalSection;
	605	+	```
590	606
591	607		Utworzenie sekcji:
592	608
593		-	~~` InitializeCriticalSection(MyCriticalSection);`~~
	609	+	```text
	610	+	InitializeCriticalSection(MyCriticalSection);
	611	+	```
594	612
595	613		Uruchomienie kilka wątków. Robienie czegoś na wyłączność:
596	614
597	615		``` pascal
598	616		EnterCriticalSection(MyCriticalSection);
599	617		try
600	618		// uzyskaj dostęp do zmiennych, zapisz pliki, wyślij pakiety sieciowe itp.
601	619		finally
602	620		LeaveCriticalSection(MyCriticalSection);
603	621		end;
604	622		```
605	623
606	624		Po zakończeniu wszystkich wątków zwolnij sekcję krytyczną:
607	625
608		-	~~` DeleteCriticalSection(MyCriticalSection);`~~
	626	+	```text
	627	+	DeleteCriticalSection(MyCriticalSection);
	628	+	```
609	629
610	630		Alternatywnie możesz użyć obiektu TCriticalSection. Inicjalizację wykonujemy przez jego utworzenie, metoda Enter wykonuje EnterCriticalSection, metoda Leave wykonuje LeaveCriticalSection, a zniszczenie obiektu powoduje jego usunięcie.
611	631
612	632		Należy zauważyć, że sekcja krytyczna nie chroni przed wprowadzeniem tego samego wątku do tego samego bloku kodu, tylko przed różnymi wątkami. Z tego powodu nie może służyć do ochrony m.in. przed ponownym wprowadzeniem do programu obsługi wiadomości (patrz sekcja wyżej).
613	633
614	634		Na przykład: 5 wątków zwiększających licznik. Zobacz lazarus/examples/multithreading/criticalsectionexample1.lpi
615	635
616	636		> Warning: Istnieją dwa zestawy powyższych czterech funkcji. Znajdują się w RTL i LCL. Te w LCL są zdefiniowane w modułach LCLIntf i LCLType. Oba działają prawie tak samo. Możesz używać obu jednocześnie w swojej aplikacji, ale nie powinieneś używać funkcji RTL w sekcji krytycznej LCL i na odwrót.
617	637
618	638		### Współdzielenie zmiennych
619	639
620	640		Jeśli niektóre wątki współdzielą zmienną, która jest tylko do odczytu, nie ma się czym martwić. Po prostu odczytaj jej wartość. Ale jeśli jeden lub kilka wątków zmienia wartość zmiennej, to musisz upewnić się, że tylko jeden wątek ma dostęp do tej zmiennej w danej chwili.
621	641
622	642		Na przykład: 5 wątków zwiększających licznik. Zobacz lazarus/examples/multithreading/criticalsectionexample1.lpi
623	643
624	644		## Oczekiwanie na inny wątek
625	645
626	646		Jeśli wątek A potrzebuje wyniku innego wątku B, musi on poczekać, aż B zakończy pracę.
627	647
628	648		Ważne: Główny wątek nigdy nie powinien czekać na kolejny wątek. Zamiast tego użyj opcji Synchronizuj (patrz wyżej).
629	649
630	650		Zobacz przykład: lazarus/examples/multithreading/waitforexample1.lpi
631	651
632	652		``` pascal
633	653		{ TThreadA }
634	654
635	655		procedure TThreadA.Execute;
636	656		begin
637	657		Form1.ThreadB:=TThreadB.Create(false);
638	658		// Utwórz zdarzenie
639	659		WaitForB:=RTLEventCreate;
640	660		while not Application.Terminated do begin
641	661		// czekaj w nieskończoność (aż B obudzi A)
642	662		RtlEventWaitFor(WaitForB);
643	663		writeln('A: ThreadB.Counter='+IntToStr(Form1.ThreadB.Counter));
644	664		end;
645	665		end;
646	666
647	667		{ TThreadB }
648	668
649	669		procedure TThreadB.Execute;
650	670		var
651	671		i: Integer;
652	672		begin
653	673		Counter:=0;
654	674		while not Application.Terminated do begin
655	675		// B: Pracuje ...
656	676		Sleep(1500);
657	677		inc(Counter);
658	678		// wybudza A
659	679		RtlEventSetEvent(Form1.ThreadA.WaitForB);
660	680		end;
661	681		end;
662	682		```
663	683
664	684		> Note: RtlEventSetEvent można wywołać przed RtlEventWaitFor. Wtedy RtlEventWaitFor natychmiast powróci. Użyj RLeventResetEvent, aby wyczyścić flagę.
665	685
666	686		## Wątek potomny, rozwidlenie (fork)
667	687
668	688		Podczas rozwidlenia w aplikacji wielowątkowej należy pamiętać, że wszelkie wątki utworzone i uruchomione PRZED wywołaniem fork (lub fpFork) NIE będą uruchomione w procesie potomnym. Jak stwierdzono na stronie podręcznika fork(), wszelkie wątki, które działały przed wywołaniem fork, będą miały stan niezdefiniowany.
669	689
670	690		Należy więc pamiętać o wszelkich wątkach inicjujących się przed wywołaniem fork (w tym w sekcji inicjowania). NIE będą działać.
671	691
672	692		## Procedury/pętle równoległe
673	693
674	694		Szczególnym przypadkiem wielowątkowości jest równoległe uruchamianie pojedynczej procedury. Zobacz [[Parallel procedures\|Procedury równoległe]].
675	695
676	696		## Obliczenia rozproszone
677	697
678	698		Następnym wyższym krokiem po wielowątkowości jest uruchamianie wątków na wielu komputerach.
679	699
680	700		- Do komunikacji można użyć jednego z pakietów TCP, takich jak synapse, lnet lub indy. Daje to maksymalną elastyczność i jest używane głównie w przypadku luźno połączonych aplikacji Klient/Serwer.
681	701		- Możesz użyć bibliotek przekazujących komunikaty, takich jak [[MPICH]], które są używane do HPC (High Performance Computing) w klastrach.
682	702
683	703		## Wątki zewnętrzne
684	704
685	705		Aby system wątków Free Pascal działał poprawnie, każdy nowo utworzony wątek FPC musi zostać zainicjowany (dokładniej muszą być zainicjowane: wyjątek, system I/O i system zmiennych dla wątków, aby działały zmienne wątków i stos). Jest to wykonywane w pełni automatycznie, jeśli używasz BeginThread (lub pośrednio za pomocą klasy TThread). Jeśli jednak używasz wątków, które zostały utworzone bez BeginThread (tj. wątków zewnętrznych), może być wymagana dodatkowa praca (obecnie). Wątki zewnętrzne obejmują również te, które zostały utworzone w zewnętrznych bibliotekach C (.DLL/.so).
686	706
687	707		Kwestie do rozważenia podczas korzystania z wątków zewnętrznych (mogą nie być potrzebne we wszystkich lub przyszłych wersjach kompilatora):
688	708
689	709		- Nie używaj w ogóle wątków zewnętrznych - używaj wątków FPC. Jeśli możesz uzyskać kontrolę nad sposobem tworzenia wątku, utwórz wątek samodzielnie za pomocą BeginThread.
690	710
691	711		Jeśli konwencja wywoływania nie pasuje (np. jeśli oryginalna funkcja wątku wymaga konwencji wywoływania cdecl, ale BeginThread wymaga konwencji Pascala, utwórz rekord, w którym przechowasz oryginalną wymaganą funkcję wątku i wywołaj tę funkcję w funkcji wątku Pascala:
692	712
693	713		``` pascal
694	714		type
695	715		TCdeclThreadFunc = function (user_data:Pointer):Pointer;cdecl;
696	716
697	717		PCdeclThreadFuncData = ^TCdeclThreadFuncData;
698	718		TCdeclThreadFuncData = record
699	719		Func: TCdeclThreadFunc; //funkcja cdecl
700	720		Data: Pointer; //oryginalne dane
701	721		end;
702	722
703	723		// Wątek Pascala wywołuje funkcję cdecl
704	724		function C2P_Translator(FuncData: pointer) : ptrint;
705	725		var
706	726		ThreadData: TCdeclThreadFuncData;
707	727		begin
708	728		ThreadData := PCdeclThreadFuncData(FuncData)^;
709	729		Result := ptrint(ThreadData.Func(ThreadData.Data));
710	730		end;
711	731
712	732		procedure CreatePascalThread;
713	733		var
714	734		ThreadData: PCdeclThreadFuncData;
715	735		begin
716	736		New(ThreadData);
717	737		// to jest pożądana funkcja wątku cdecl
718	738		ThreadData^.Func := func;
719	739		ThreadData^.Data := user_data;
720	740		// to tworzy wątek Pascala
721	741		BeginThread(@C2P_Translator, ThreadData );
722	742		end;
723	743		```
724	744
725	745		- Zainicjuj system wątków FPC, tworząc fikcyjny wątek. Jeśli nie utworzysz żadnego wątku Pascala w swojej aplikacji, system wątków nie zostanie zainicjowany (a zatem zmienne wątków nie będą działać, a zatem i stos nie będzie działać poprawnie).
726	746
727	747		``` pascal
728	748		type
729	749		tc = class(tthread)
730	750		procedure execute;override;
731	751		end;
732	752
733	753		procedure tc.execute;
734	754		begin
735	755		end;
736	756
737	757		{ main program }
738	758		begin
739	759		{ zainicjować system wątków }
740	760		with tc.create(false) do
741	761		begin
742	762		waitfor;
743	763		free;
744	764		end;
745	765		{ ... Twój kod wykonywany dalej }
746	766		end.
747	767		```
748	768
749	769		(Po zainicjowaniu systemu wątków środowisko wykonawcze może ustawić zmienną systemową „IsMultiThread” na wartość true, która jest używana przez procedury FPC do wykonywania blokad tu i tam. Nie należy ustawiać tej zmiennej ręcznie.)
750	770
751	771		- Jeśli z jakiegoś powodu to nie działa, wypróbuj ten kod w funkcji wątku zewnętrznego:
752	772
753	773		``` pascal
754	774		function ExternalThread(param: Pointer): LongInt; stdcall;
755	775		var
756	776		tm: TThreadManager;
757	777		begin
758	778		GetThreadManager(tm);
759	779		tm.AllocateThreadVars;
760	780		InitThread(1000000); // dostosuj tutaj początkowy rozmiar stosu
761	781
762	782		{ zrób tutaj coś w wątku ... }
763	783
764	784		Result:=0;
765	785		end;
766	786		```
767	787
768	788		### Identyfikacja wątków zewnętrznych
769	789
770	790		Czasami nawet nie wiesz, czy masz do czynienia z wątkami zewnętrznymi (np. czy jakaś biblioteka C wykonuje wywołanie zwrotne). To może pomóc w analizie takiej sytuacji:
771	791
772	792		1\. Zapytaj system operacyjny o identyfikator bieżącego wątku podczas uruchamiania aplikacji
773	793
774	794		``` pascal
775	795		GetCurrentThreadID() //windows;
776	796		GetThreadID() //Darwin/macOS;
777	797		TThreadID(pthread_self) //Linux;
778	798		```
779	799
780	800		2\. Zapytaj ponownie o identyfikator bieżącego wątku wewnątrz funkcji wątku i porównaj to z wynikiem kroku 1.
781	801
782	802		### Dodawanie opóźnień czasowych
783	803
784	804		ThreadSwitch()
785	805
786	806		> Note: Nie używaj sztuczki z uśpieniem w Windows Sleep(0) ponieważ nie będzie to działać na wszystkich platformach.
787	807
788	808		## Zobacz także
789	809
790	810		- [[Streaming components\|Komponenty strumieniowe]]
791	811		- [[Manager Worker Threads System\|System nadzorowania wątków roboczych]]
792	812		- [[Example of multi-threaded application: array of threads/pl\|Przykład aplikacji wielowątkowej: tablicy wątków]]
793	813		- [[Parallel procedures\|Procedury równoległe]]
794	814		- [[Main Loop Hooks\|Petla gówna uchwytów]]
795	815		- [[Asynchronous Calls\|Wywołanie asynchroniczne]]
796	816		- [Mutlithreading - The Delphi way](http://nickhodges.com/MultiThreadingInDelphi/ToC.html)
797	817
798	818		---
799	819		From the Free Pascal wiki, page "Multithreaded Application Tutorial/pl", as it stood on 2023-09-23 after a change by Slawek, 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