Multithreaded Application Tutorial/ru: what changed

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

Old	New		Line
1	1		## Обзор
2	2
3	3		Эта страница объясняет как писать и отлаживать многопоточные(multi-threaded) приложения средствами Free Pascal и Lazarus. Многопоточное приложение — это приложение, которое создаёт два или более потока исполнения, работающих одновременно. Если Вы новичок в многопоточности, пожалуйста, прочитайте раздел "Нужна ли на самом деле многопоточность?" чтобы определить, что это действительно необходимо.
4	4
5	5		Один из потоков называется главным, основным (Main Thread). Главный поток создаётся операционной системой после запуска приложения. Главный поток должен быть единственным потоком, который обновляет компоненты, взаимодействующие с пользователем: иначе приложение может зависнуть.
6	6
7	7		Основная идея состоит в том, что приложение может производить некоторую обработку в фоновом режиме во втором потоке, а пользователь может продолжать работу с помощью основного потока.
8	8
9	9		Другое использование потоков состоит в лучшей отзывчивости (responding) приложения. Если вы создали приложение, где пользователь нажимает на кнопку, обрабатывающую большой объём работы, во время обработки экран перестаёт отвечать на запросы и пользователь думает, что приложение не отвечает. Создаётся плохое и вводящее в заблуждение впечатление. Если это задание выполняется во втором потоке, приложение сохраняет работоспособную форму (почти), как будто оно находится в состоянии простоя. В этом смысле это хорошая идея перед запуском потока выключить кнопки на форме, позволяющие пользователю запустить более чем один поток для работы.
10	10
11	11		Другим способом использования многопоточности может быть серверное приложение, которое одновременно отвечает многим клиентам.
12	12
13	13		## Нужна ли на самом деле многопоточность?
14	14
15	15		Если Вы новичок в многопоточности и хотите только чтобы Ваше приложение отвечало на действия пользователя, пока оно выполняет задачи умеренной длительности, тогда мультипоточность, возможно, это избыточное средство.
16	16
17	17		Многопоточные приложения всегда более сложные в отладке и зачастую они имеют гораздо более сложную структуру; во многих случаях Вам не нужна многопоточность. Одного потока вполне достаточно. Если Вы можете разделить трудоёмкую задачу на несколько небольших частей, тогда вместо многопоточности Вы должны использовать Application.ProcessMessages. Этот метод позволяет LCL обрабатывать все ожидающие сообщений и возвращения (messages and returns). Центральной идеей является вызов Application.ProcessMessages в одинаковые промежутки в ходе выполнения длительной задачи чтобы определить, нажал ли пользователь куда-нибудь или индикатор прогресса должен быть перерисован, и так далее.
18	18
19	19		К примеру, чтение большого файла и его обработки См. examples/multithreading/singlethreadingexample1.lpi.
20	20
21	21		Многопоточность необходима только для:
22	22
23	23		- блокировки handles, таких как сетевое соединение
24	24		- использования нескольких процессоров одновременно (multiple processors simultaneously, SMP)
25	25		- вызовы алгоритмов и библиотек, которые должны вызываться через API, т.к. они не могут быть разделены на мелкие части.
26	26
27	27		## Модули, необходимые для многопоточного приложения
28	28
29	29		Вам не нужен какой-либо специальный модуль для работы с Windows. Однако с Linux, macOS и FreeBSD вам нужен модуль `cthreads`, и он должен быть первым используемым модулем проекта (в исходнике программы, обычно файл .lpr)! В случаях, когда потребуется разместить одновременно несколько "важных" модулей, таких как `cthreads`, `cmem` и `cwstrings`, ввиду особенностей их работы оптимальным порядком размещения будет `cmem`, `cthreads`, и лишь затем `cwstrings`.
30	30
31	31		Итак, код вашего приложения Lazarus должен выглядеть так:
32	32
33	33		``` pascal
34	34		program MyMultiThreadedProgram;
35	35		{$mode objfpc}{$H+}
36	36		uses
37	37		{$ifdef unix}
38	38		cthreads,
39	39		cmem, // диспетчер памяти C в некоторых системах намного быстрее для многопоточности
40	40		{$endif}
41	41		Interfaces, // это включает в себя набор виджетов LCL
42	42		Forms
43	43		{ Вы можете добавить другие модули здесь },
44	44		```
45	45
46	46		Если вы забудете об этом и используете TThread (не добавив для nix-ов cthreads), вы получите эту ошибку при запуске:
47	47
48		-	~~` This binary has no thread support compiled in.`\~~
49		-	~~` Recompile the application with a thread-driver in the program uses clause before other units using thread.`\~~
50		-	~~` { В этом двоичном файле нет поддержки потоков.}`\~~
51		-	` {Перекомпилируйте приложение с драйвером потока, указанном в разделе uses программы перед другими модулями, использующими поток.}`
	48	+	``` pascal
	49	+	This binary has no thread support compiled in.
	50	+	Recompile the application with a thread-driver in the program uses clause before other units using thread.
	51	+	{ В этом двоичном файле нет поддержки потоков.}
	52	+	{Перекомпилируйте приложение с драйвером потока, указанном в разделе uses программы перед другими модулями, использующими поток.}
	53	+	```
52	54
53	55		> Note: Если вы получаете ошибку компоновщика о том, что "mcount" не найден, значит, вы используете какой-то модуль, содержащий многопоточный код, и вам нужно добавить модуль `cthreads` или использовать интеллектуальное связывание.
54	56
55	57		> Note: Если вы получаете ошибку: "Project raised exception class 'RunError(232)'" в процедуре SYSTEM_NOTHREADERROR, то ваш код требует многопоточности и вам необходимо добавить модуль cthreads.
56	58
57	59		## Простейший пример FPC
58	60
59	61		Приведенный ниже код дает очень простой пример. Проверено с помощью FPC 3.0.4 на Win7.
60	62
61	63		``` pascal
62	64		Program ThreadTest;
63	65		{тестирование возможности многопоточности}
64	66		{
65	67		OUTPUT
66	68		thread 1 started
67	69		thread 1 thri 0 Len(S)= 1
68	70		thread 1 thri 1 Len(S)= 2
69	71		thread 1 thri 2 Len(S)= 3
70	72		thread 1 thri 3 Len(S)= 4
71	73		thread 1 thri 4 Len(S)= 5
72	74		thread 1 thri 5 Len(S)= 6
73	75		thread 1 thri 6 Len(S)= 7
74	76		thread 1 thri 7 Len(S)= 8
75	77		thread 1 thri 8 Len(S)= 9
76	78		thread 1 thri 9 Len(S)= 10
77	79		thread 1 thri 10 Len(S)= 11
78	80		thread 1 thri 11 Len(S)= 12
79	81		thread 1 thri 12 Len(S)= 13
80	82		thread 1 thri 13 Len(S)= 14
81	83		thread 1 thri 14 Len(S)= 15
82	84		thread 2 started
83	85		thread 3 started
84	86		thread 1 thri 15 Len(S)= 16
85	87		thread 2 thri 0 Len(S)= 1
86	88		thread 3 thri 0 Len(S)= 1
87	89		thread 1 thri 16 Len(S)= 17
88	90		...
89	91		...
90	92		thread 5 thri 997 Len(S)= 998
91	93		thread 5 thri 998 Len(S)= 999
92	94		thread 5 thri 999 Len(S)= 1000
93	95		thread 5 finished
94	96		thread 10 thri 828 Len(S)= 829
95	97		thread 9 thri 675 Len(S)= 676
96	98		thread 4 thri 656 Len(S)= 657
97	99		thread 10 thri 829 Len(S)= 830
98	100		thread 9 thri 676 Len(S)= 677
99	101		thread 9 thri 677 Len(S)= 678
100	102		thread 10 thri 830 Len(S)= 831
101	103		thread 10 thri 831 Len(S)= 832
102	104		thread 10 thri 832 Len(S)= 833
103	105		thread 10 thri 833 Len(S)= 834
104	106		thread 10 thri 834 Len(S)= 835
105	107		thread 10 thri 835 Len(S)= 836
106	108		thread 10 thri 836 Len(S)= 837
107	109		thread 10 thri 837 Len(S)= 838
108	110		thread 10 thri 838 Len(S)= 839
109	111		thread 10 thri 839 Len(S)= 840
110	112		thread 9 thri 678 Len(S)= 679
111	113		...
112	114		...
113	115		thread 4 thri 994 Len(S)= 995
114	116		thread 4 thri 995 Len(S)= 996
115	117		thread 4 thri 996 Len(S)= 997
116	118		thread 4 thri 997 Len(S)= 998
117	119		thread 4 thri 998 Len(S)= 999
118	120		thread 4 thri 999 Len(S)= 1000
119	121		thread 4 finished
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('thread ',longint(p),' started');
142	144		thri:=0;
143	145		while (thri<stringlen) do begin
144	146		s:=s+'1'; { create a delay }
145	147		writeln('thread ',longint(p),' thri ',thri,' Len(S)= ',length(s));
146	148		inc(thri);
147	149		end;
148	150		Writeln('thread ',longint(p),' finished');
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		## Класс TThread
166	168
167	169		Самый простой путь для создания многопоточного приложения — использование класса TThread. Этот класс позволяет достаточно просто создать дополнительный поток (наряду с основным). Обычно от вас требуется переопределить только 2 метода: конструктор Create, и метод Execute.
168	170
169	171		В конструкторе Вы подготавливаете поток для запуска. Вы устанавливаете начальные значения переменных и свойств, которые Вам нужны. Подлинный конструктор TThread требует параметр, называющийся Suspended (приостановить). Как и следует ожидать, установка Suspended = True будет препятствовать автоматическому запуску потоков после создания. Если Suspended = False, поток запускается сразу после создания. Если поток создан приостановленным (Suspended = True), тогда он запускается только после вызова метода Resume.
170	172
171	173		В FPC version 2.0.1 и более поздних, TThread.Create также имеет неявный параметр, отвечающий за размер стека. Теперь, если это необходимо, Вы можете изменить стандартный размер стека каждого потока, который Вы создали. Глубокая рекурсия в процедурах является хорошим примером. Если Вы не изменяете размер стека, используется стандартный размер стека операционной системы.
172	174
173	175		В переопределённом методе Execute Вы будете писать код, который запускается в потоке.
174	176
175	177		Класс TThread имеет одно важное свойство: Terminated : Boolean;
176	178
177	179		Если поток имеет цикл (loop) — и это нормально, — выход из цикла должен осуществиться, когда Terminated = True (по умолчанию – False). В каждом проходе значение свойство Terminated должно проверяться, и если оно True, цикл должен завершиться так быстро, как это возможно, после необходимой очистки. Имейте ввиду, что метод Terminate по умолчанию ничего не делает: в метод Execute нужно явно организовать завершение задания.
178	180
179	181		Как мы объяснили ранее, поток не должен взаимодействовать с видимыми компонентами. Обновления для видимой компоненты должны быть сделаны в контексте главного, основного потока. Чтобы это сделать, у TThread существует метод, называющийся Synchronize. Synchronize требует метод в качестве аргумента. Когда вы вызываете метод через Synchronize(@MyMethod), запущенный поток приостанавливается, код метода MyMethod запускается в главном потоке, а затем выполнение потока будет продолжено. Точная обработка Synchronize зависит от платформы, но упрощённо он делает следующее: он посылает сообщение в главную очередь сообщений и приостанавливает своё выполнение(goes to sleep). В конечном итоге главный поток обрабатывает сообщение и вызывает MyMethod. Таким образом, MyMethod вызывается без контекста, то есть не во время события OnMouseDown или в течение события перерисовки (paint event), но после этого. После того, как главный поток запускает MyMethod, он будит спящий поток и обрабатывает следующее сообщение из главной очереди сообщений, а поток продолжает работать.
180	182
181	183		Существует другое важное свойство TThread: FreeOnTerminate. Если оно True, тогда объект потока автоматически освобождается, когда выполнение потока (метод Execute) останавливается. В противном случае, приложению будет необходимо освободить его вручную.
182	184
183	185		Следующий пример может быть найден в каталоге examples/multithreading/:
184	186
185	187		``` pascal
186	188		Type
187	189		TMyThread = class(TThread)
188	190		private
189	191		fStatusText : string;
190	192		procedure ShowStatus;
191	193		protected
192	194		procedure Execute; override;
193	195		public
194	196		Constructor Create(CreateSuspended : boolean);
195	197		end;
196	198
197	199		constructor TMyThread.Create(CreateSuspended : boolean);
198	200		begin
199	201		FreeOnTerminate := True;
200	202		inherited Create(CreateSuspended);
201	203		end;
202	204
203	205		procedure TMyThread.ShowStatus;
204	206		// этот метод запущен главным потоком и поэтому может получить доступ ко всем элементам графического интерфейса.
205	207		begin
206	208		Form1.Caption := fStatusText;
207	209		end;
208	210
209	211		procedure TMyThread.Execute;
210	212		var
211	213		newStatus : string;
212	214		begin
213	215		fStatusText := 'TMyThread Starting...';
214	216		Synchronize(@Showstatus);
215	217		fStatusText := 'TMyThread Running...';
216	218		while (not Terminated) and ([любое необходимое условие]) do
217	219		begin
218	220		...
219	221		{здесь расположен код цикла главного (основного) потока}
220	222		...
221	223		if NewStatus <> fStatusText then
222	224		begin
223	225		fStatusText := newStatus;
224	226		Synchronize(@Showstatus);
225	227		end;
226	228		end;
227	229		end;
228	230		```
229	231
230	232		В приложении
231	233
232	234		``` pascal
233	235		var
234	236		MyThread : TMyThread;
235	237		begin
236	238		MyThread := TMyThread.Create(True); // Таким способом он не запустится автоматически
237	239		...
238	240		{Здесь расположен код, который инициализирует всё возможное перед запуском потоков}
239	241		...
240	242		MyThread.Resume;
241	243		end;
242	244		```
243	245
244	246		Если вы хотите, чтобы ваши приложения были более гибкими, Вы можете создавать события для потока; таким образом, Ваши синхронизированные методы не будут тесно связаны с определенной формой или классом: Вы можете прикрепить слушателей событий потока. Вот пример:
245	247
246	248		``` pascal
247	249		Type
248	250		TShowStatusEvent = procedure(Status: String) of Object;
249	251
250	252		TMyThread = class(TThread)
251	253		private
252	254		fStatusText : string;
253	255		FOnShowStatus: TShowStatusEvent;
254	256		procedure ShowStatus;
255	257		protected
256	258		procedure Execute; override;
257	259		public
258	260		Constructor Create(CreateSuspended : boolean);
259	261		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
260	262		end;
261	263
262	264		constructor TMyThread.Create(CreateSuspended : boolean);
263	265		begin
264	266		FreeOnTerminate := True;
265	267		inherited Create(CreateSuspended);
266	268		end;
267	269
268	270		procedure TMyThread.ShowStatus;
269	271		// этот метод запущен главным потоком и поэтому может получить доступ ко всем элементам графического интерфейса.
270	272		begin
271	273		if Assigned(FOnShowStatus) then
272	274		begin
273	275		FOnShowStatus(fStatusText);
274	276		end;
275	277		end;
276	278
277	279		procedure TMyThread.Execute;
278	280		var
279	281		newStatus : string;
280	282		begin
281	283		fStatusText := 'TMyThread Starting...';
282	284		Synchronize(@Showstatus);
283	285		fStatusText := 'TMyThread Running...';
284	286		while (not Terminated) and ([любое необходимое условие]) do
285	287		begin
286	288		...
287	289		{здесь расположен код цикла главного (основного) потока}
288	290		...
289	291		if NewStatus <> fStatusText then
290	292		begin
291	293		fStatusText := newStatus;
292	294		Synchronize(@Showstatus);
293	295		end;
294	296		end;
295	297		end;
296	298		```
297	299
298	300		В приложении
299	301
300	302		``` pascal
301	303		Type
302	304		TForm1 = class(TForm)
303	305		Button1: TButton;
304	306		Label1: TLabel;
305	307		procedure FormCreate(Sender: TObject);
306	308		procedure FormDestroy(Sender: TObject);
307	309		private
308	310		{ private declarations }
309	311		MyThread: TMyThread;
310	312		procedure ShowStatus(Status: string);
311	313		public
312	314		{ public declarations }
313	315		end;
314	316
315	317		procedure TForm1.FormCreate(Sender: TObject);
316	318		begin
317	319		inherited;
318	320		MyThread := TMyThread.Create(true);
319	321		MyThread.OnShowStatus := @ShowStatus;
320	322		end;
321	323
322	324		procedure TForm1.FormDestroy(Sender: TObject);
323	325		begin
324	326		MyThread.Terminate;
325	327		MyThread.Free;
326	328		inherited;
327	329		end;
328	330
329	331		procedure TForm1.Button1Click(Sender: TObject);
330	332		begin
331	333		MyThread.Resume;
332	334		end;
333	335
334	336		procedure TForm1.ShowStatus(Status: string);
335	337		begin
336	338		Label1.Caption := Status;
337	339		end;
338	340		```
339	341
340	342		## Важно знать
341	343
342	344		### Проверка стека в Windows
343	345
344	346		Существует потенциальная проблема с потоками в Windows, если Вы используете переключатель (?) -Ct (stack check). По причинам не совсем понятным проверка стека "переключается" при любом TThread.Create если Вы используете размер стек по-умолчанию.
345	347
346	348		Единственный работающий способ на данный момент - просто не использовать переключатель -Ct. Заметим, что это не вызывает исключения в основном потоке, но вызывает в недавно созданном. Это "выглядит" как если бы поток никогда не был запущен.
347	349
348	350		Хороший код для проверки этого и других исключений, которые могут возникнуть в создании потоков:
349	351
350	352		``` pascal
351	353		MyThread:=TThread.Create(False);
352	354		if Assigned(MyThread.FatalException) then
353	355		raise MyThread.FatalException;
354	356		```
355	357
356	358		Этот код будет гарантировать, что любое исключение, которое произошло во время создания потока будет распространёно на главный поток.
357	359
358	360		### Функция GetDC на Windows
359	361
360	362		Функция GetDC (и GetDCEx) извлекает хэндл контекста устройства (DC) для клиентской области указанного окна или для всего экрана. Ее можно использовать, например, для [[Developing with Graphics\|создания снимка экрана]]. Однако обратите внимание, что эта функция не является потокобезопасной: хэндл к DC может использоваться только одним потоком в любой момент времени, как [описано здесь](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdc).
361	363
362	364		### Многопоточность в пакетах
363	365
364	366		Пакеты, использующие многопоточность, должны добавлять флаг -dUseCThreads в пользовательские параметры использования. Откройте редактор пакета, затем Options \> Usage \> Custom и добавьте -dUseCThreads. Это определит данный флаг для всех проектов и пакетов, использующих этот пакет, включая IDE. IDE и все новые приложения, созданные IDE, уже имеют следующий код в своем .lpr-файле:
365	367
366	368		``` pascal
367	369		uses
368	370		{$IFDEF UNIX}{$IFDEF UseCThreads}
369	371		cthreads,
370	372		cmem, // менеджер памяти Си в некоторых системах намного быстрее для многопоточности
371	373		{$ENDIF}{$ENDIF}
372	374		```
373	375
374	376		### Heaptrc
375	377
376	378		Вы не можете использовать ключ -gh с модулем cmem. Ключ -gh использует модуль heaptrc, который расширяет менеджер кучи. Поэтому модуль heaptrc должен указываться после модуля cmem.
377	379
378	380		``` pascal
379	381		uses
380	382		{$IFDEF UNIX}{$IFDEF UseCThreads}
381	383		cthreads,
382	384		cmem, // менеджер памяти Си в некоторых системах намного быстрее для многопоточности
383	385		{$ENDIF}{$ENDIF}
384	386		heaptrc,
385	387		```
386	388
387	389		### Initialization и Finalization
388	390
389	391		Чтобы инициализировать сам объект потока, вы можете либо запустить его в приостановленном состоянии и задать его свойства и/или создать новый конструктор и вызвать унаследованный конструктор.
390	392
391	393		Примечание: Использование AfterConstruction при `CreateSuspended=false` опасно, так как поток уже запущен.
392	394
393	395		С другой стороны, деструктор может быть использован для завершения использования ресурсов объекта.
394	396
395	397		``` pascal
396	398		type
397	399		TMyThread = class(TThread)
398	400		private
399	401		fRTLEvent: PRTLEvent;
400	402		public
401	403		procedure Create(SomeData: TSomeObject); override;
402	404		destructor Destroy; override;
403	405		end;
404	406
405	407		procedure TMyThread.Create(SomeData: TSomeObject; CreateSuspended: boolean);
406	408		begin
407	409		// например: настройка событий, критических секций и других ресурсов, таких как файлы или соединения с базой данных
408	410		RTLEventCreate(fRTLEvent);
409	411		inherited Create(CreateSuspended);
410	412		end;
411	413
412	414		destructor TMyThread.Destroy;
413	415		begin
414	416		RTLeventDestroy(fRTLEvent);
415	417		inherited Destroy;
416	418		end;
417	419		```
418	420
419	421		### Не LCL-программы
420	422
421	423		TThread.Synchronize требует, чтобы главный поток регулярно вызывал CheckSynchronize. LCL делает это в своем цикле. Если вы не используете цикл событий LCL, вы должны вызывать его самостоятельно.
422	424
423	425		## Поддержка SMP
424	426
425	427		Хорошей новостью является то, что если ваше приложение работает все-таки правильно в многопоточном режиме, то оно уже поддерживает SMP!
426	428
427	429		## Отладка многопоточных приложений с помощью Lazarus
428	430
429	431		Отладка на Lazarus требует GDB и быстро становится все более полнофункциональной и стабильной. Однако до сих пор существует несколько дистрибутивов Linux с некоторыми проблемами.
430	432
431	433		### Вывод отладочной информации
432	434
433	435		В однопоточном приложении вы можете просто писать в консоль/терминал/что угодно, и порядок строк будет таким же, как они были записаны. В многопоточном приложении все сложнее. Если пишут два потока, скажем, строка написана потоком A перед строкой потока B, то строки не обязательно будут записаны в таком порядке. В то время как в linux (возможно) вы получите правильный вывод [[DebugLn]](), то в win32 вы можете получить исключения (возможно DiskFull) из-за использования DebugLn() вне основного потока. Поэтому, чтобы избежать головной боли, используйте DebugLnThreadLog(), упомянутый ниже.
434	436
435	437		Модуль LCLProc содержит несколько функций, позволяющих каждому потоку писать в свой собственный файл журнала:
436	438
437	439		``` pascal
438	440		procedure DbgOutThreadLog(const Msg: string); overload;
439	441		procedure DebuglnThreadLog(const Msg: string); overload;
440	442		procedure DebuglnThreadLog(Args: array of const); overload;
441	443		procedure DebuglnThreadLog; overload;
442	444		```
443	445
444	446		Например: Вместо writeln('Some text ',123); задействуйте
445	447
446		-	~~` DebuglnThreadLog(['Some text ',123]);`~~
	448	+	```text
	449	+	DebuglnThreadLog(['Some text ',123]);
	450	+	```
447	451
448	452		Это добавит строку 'Some text 123' в Log\<PID\>.txt, где \<PID\> - идентификатор процесса текущего потока.
449	453
450	454		Хорошей идеей будет удаление файлов журнала перед каждым запуском:
451	455
452		-	~~` rm -f Log* && ./project1`~~
	456	+	```text
	457	+	rm -f Log* && ./project1
	458	+	```
453	459
454	460		### Linux
455	461
456	462		Если вы попытаетесь отладить многопоточное приложение в Linux, вы столкнетесь с одной большой проблемой: менеджер рабочего стола на X-сервере может зависнуть. Это происходит, например, когда приложение захватило мышь/клавиатуру и было приостановлено gdb, а X-сервер ждет вашего приложения. Когда это происходит, вы можете просто войти в систему с другого компьютера и убить gdb или выйти из этой сессии, нажав `CTRL`+`ALT`+`F3` и убить gdb. В качестве альтернативы вы можете перезапустить оконный менеджер: введите
457	463
458		-	~~` sudo /etc/init.d/gdm restart. `~~
	464	+	```text
	465	+	sudo /etc/init.d/gdm restart.
	466	+	```
459	467
460	468		Это перезапустит менеджер рабочего стола и вернет вас на рабочий стол.
461	469
462	470		Поскольку это зависит от того, где gdb останавливает вашу программу, в некоторых случаях могут помочь некоторые хитрости: для Ubuntu x64 установите в опциях проекта для отладки требуемый файл дополнительной информации...
463	471
464		-	~~` Project Options -> Compiler Options -> Linking -> Debugging: Check Use external gdb debug symbols file (-Xg).`~~
	472	+	```text
	473	+	Project Options -> Compiler Options -> Linking -> Debugging: Check Use external gdb debug symbols file (-Xg).
	474	+	```
465	475
466	476		Другой вариант - открыть другой рабочий стол X, запустить IDE/gdb на одном и приложение на другом, чтобы зависал только тестовый рабочий стол. Создайте новый экземпляр X с:
467	477
468		-	~~` X :1 &`~~
	478	+	```text
	479	+	X :1 &
	480	+	```
469	481
470	482		Он откроется, и когда вы переключитесь на другой рабочий стол (тот, с которым вы работаете, нажав `CTRL`+`ALT`+`F7`), вы сможете вернуться на новый графический рабочий стол с помощью `CTRL`+`ALT`+`F8` (если эта комбинация не работает, попробуйте `CTRL`+`ALT`+`F2`... этот вариант работал на [Slackware](http://www.slackware.com)).
471	483
472	484		Затем вы можете, если хотите, создать сеанс рабочего стола на X, с которого начался сеанс:
473	485
474		-	~~` gnome-session --display=:1 &`~~
	486	+	```text
	487	+	gnome-session --display=:1 &
	488	+	```
475	489
476	490		Затем в Lazarus, в диалоге параметров запуска проекта, отметьте "Use display" и введите :1.
477	491
478	492		Теперь приложение будет запущено на втором X-сервере, и вы сможете отлаживать его на первом.
479	493
480	494		Это было проверено с Free Pascal 2.0 и Lazarus 0.9.10 на Windows и Linux.
481	495
482	496		------------------------------------------------------------------------
483	497
484	498		Вместо создания новой X-сессии можно использовать [Xnest](http://en.wikipedia.org/wiki/Xnest). Xnest - это X-сессия в окне. Используя его, X-сервер не блокируется при отладке потоков, и отлаживать гораздо проще, не меняя терминалы.
485	499
486	500		Командная строка для запуска Xnest выглядит следующим образом
487	501
488		-	~~` Xnest :1 -ac`~~
	502	+	```text
	503	+	Xnest :1 -ac
	504	+	```
489	505
490	506		для создания X-сессии на :1 и отключения контроля доступа.
491	507
492	508		## Интерфейсы виджетов Lazarus
493	509
494	510		Интерфейсы win32, gtk и carbon поддерживают многопоточность. Это означает, что TThread, критические секции и Synchronize работают. Но они не являются потокобезопасными. Это означает, что только один поток в одно время может получить доступ к LCL. А поскольку главный поток никогда не должен ждать другого потока, это означает, что только главный поток имеет доступ к LCL, то есть ко всему, что связано с TControl, Application и дескрипторами виджетов LCL. В LCL есть несколько потокобезопасных функций. Например, большинство функций в блоке FileUtil являются потокобезопасными.
495	511
496	512		### Использование SendMessage/PostMessage для взаимодействия между потоками
497	513
498	514		Только один поток в приложении должен вызывать API LCL, обычно это главный поток. Другие потоки могут использовать LCL с помощью ряда косвенных методов, одним из хороших вариантов является использование SendMessage или PostMessage. LCLIntf.SendMessage и LCLIntf.PostMessage отправляют сообщение в окно пула сообщений приложения.
499	515
500	516		См. также документацию по этим процедурам:
501	517
502	518		- [[doc:lcl/lclintf/sendmessage.html\|SendMessage]]
503	519		- [[doc:lcl/lclintf/postmessage.html\|PostMessage]]
504	520
505	521		Разница между SendMessage и PostMessage заключается в том, как они возвращают управление вызывающему потоку. Как и Synchronize, SendMessage блокирует и управление не возвращается, пока окно, в которое было отправлено сообщение, не завершит его обработку; однако при определенных обстоятельствах SendMessage может попытаться оптимизировать обработку, оставаясь в контексте вызвавшего его потока. При PostMessage управление возвращается немедленно до некоторого определенного системой максимального количества поставленных в очередь сообщений и до тех пор, пока в куче остается место для вложенных данных.
506	522
507	523		В обоих случаях процедура, обрабатывающая сообщение (см. ниже), должна избегать вызова application.ProcessMessages, поскольку это может привести к отправке второго сообщения, которое будет обрабатываться реентерабельно. Если это неизбежно, то предпочтительнее использовать другой механизм для передачи сериализованных событий между потоками.
508	524
509	525		Вот пример того, как вторичный поток может посылать текст для отображения в элементе управления LCL главному потоку:
510	526
511	527		``` pascal
512	528		const
513	529		WM_GOT_ERROR = LM_USER + 2004;
514	530		WM_VERBOSE = LM_USER + 2005;
515	531
516	532		procedure VerboseLog(Msg: string);
517	533		var
518	534		PError: PChar;
519	535		begin
520	536		if MessageHandler = 0 then Exit;
521	537		PError := StrAlloc(Length(Msg)+1);
522	538		StrCopy(PError, PChar(Msg));
523	539		PostMessage(formConsole.Handle, WM_VERBOSE, Integer(PError), 0);
524	540		end;
525	541		```
526	542
527	543		И пример того, как обработать это сообщение из окна:
528	544
529	545		``` pascal
530	546		const
531	547		WM_GOT_ERROR = LM_USER + 2004;
532	548		WM_VERBOSE = LM_USER + 2005;
533	549
534	550		type
535	551		{ TformConsole }
536	552
537	553		TformConsole = class(TForm)
538	554		DebugList: TListView;
539	555		// ...
540	556		private
541	557		procedure HandleDebug(var Msg: TLMessage); message WM_VERBOSE;
542	558		end;
543	559
544	560		var
545	561		formConsole: TformConsole;
546	562
547	563		implementation
548	564
549	565		....
550	566
551	567		{ TformConsole }
552	568
553	569		procedure TformConsole.HandleDebug(var Msg: TLMessage);
554	570		var
555	571		Item: TListItem;
556	572		MsgStr: PChar;
557	573		MsgPasStr: string;
558	574		begin
559	575		MsgStr := PChar(Msg.wparam);
560	576		MsgPasStr := StrPas(MsgStr);
561	577		Item := DebugList.Items.Add;
562	578		Item.Caption := TimeToStr(SysUtils.Now);
563	579		Item.SubItems.Add(MsgPasStr);
564	580		Item.MakeVisible(False);
565	581
566	582		// Далее следует что-то вроде
567	583
568	584		TrayControl.SetError(MsgPasStr);
569	585		StrDispose(MsgStr)
570	586		end;
571	587
572	588		end.
573	589		```
574	590
575	591		Когда на машине Linux x64 возникает ошибка: "Project XY raised exception class 'External: SIGSEGV'", необходимо изменить "Integer(PError)" на "PtrInt(PError)" в процедуре "VerboseLog". Измененная строка должна выглядеть следующим образом:
576	592
577		-	~~` PostMessage(formConsole.Handle, WM_VERBOSE, PtrInt(PError), 0);`~~
	593	+	```text
	594	+	PostMessage(formConsole.Handle, WM_VERBOSE, PtrInt(PError), 0);
	595	+	```
578	596
579	597		## Критические секции
580	598
581	599		Критическая секция представляет собой объект, который используется, чтобы удостовериться, что некоторые части кода выполняются только одним \[конкурирующим\] потоком одновременно. Критическая секция должна быть создана/инициализирована прежде, чем она может быть использована и будет освобождена, когда она не нужна.
582	600
583	601		Критические секции обычно используются следующим образом:
584	602
585	603		Добавляем модуль SyncObjs.
586	604
587	605		Объявляем секцию (для всех потоков, которые будут использовать этот раздел):
588	606
589		-	~~` MyCriticalSection: TRTLCriticalSection;`~~
	607	+	```text
	608	+	MyCriticalSection: TRTLCriticalSection;
	609	+	```
590	610
591	611		Создаём секцию:
592	612
593		-	~~` InitializeCriticalSection(MyCriticalSection);`~~
	613	+	```text
	614	+	InitializeCriticalSection(MyCriticalSection);
	615	+	```
594	616
595	617		Запускаем несколько потоков. Делаем что-нибудь \[в монопольном режиме\]:
596	618
597	619		``` pascal
598	620		EnterCriticalSection(MyCriticalSection);
599	621		try
600	622		// доступ к переменным, запись файлов, отправка сетевых пакетов, и т.д.
601	623		finally
602	624		LeaveCriticalSection(MyCriticalSection);
603	625		end;
604	626		```
605	627
606	628		После завершения всех потоков, освобождаем её:
607	629
608		-	~~` DeleteCriticalSection(MyCriticalSection);`~~
	630	+	```text
	631	+	DeleteCriticalSection(MyCriticalSection);
	632	+	```
609	633
610	634		В качестве альтернативы вы можете использовать объект TCriticalSection. Создание \[объекта\] выполняет инициализацию, метод Enter выполняет EnterCriticalSection, метод Leave выполняет LeaveCriticalSection, а удаление объекта - \[его\] удаление.
611	635
612	636		Например: 5 потоков инкрементируют счетчик: см. lazarus/examples/multithreading/criticalsectionexample1.lpi
613	637
614	638		Осторожно: Есть два набора из 4 вышеуказанных функций. По одному из RTL и LCL. \[Для\] LCL \[функции\] определены в модуле LCLIntf и LCLType. Оба \[набора\] работают почти одинаково. Вы можете использовать оба \[набора функций\] в одном приложении одновременно, но не должны использовать функции RTL с критическими секциями LCL и наоборот.
615	639
616	640		### Общие переменные
617	641
618	642		Если неcколько потоков обращаются к переменной, которая предназначена только для чтения, то не о чем беспокоиться. Но если один или несколько потоков изменяют переменную, то необходимо убедиться в том, что в данный момент времени только один поток имеет доступ к ней.
619	643
620	644		Пример: 5 потоков увеличивают переменную-счётчик. см. lazarus/examples/multithreading/criticalsectionexample1.lpi
621	645
622	646		## Ожидание другого потока
623	647
624	648		Если потоку A необходим результат работы другого потока B, он должен ждать пока работа потока B будет завершена.
625	649
626	650		Важно: Главный поток никогда не должен ждать другой поток. Вместо этого используйте Synchronize (см. выше).
627	651
628	652		Пример: lazarus/examples/multithreading/waitforexample1.lpi
629	653
630	654		``` pascal
631	655		{ TThreadA }
632	656
633	657		procedure TThreadA.Execute;
634	658		begin
635	659		Form1.ThreadB:=TThreadB.Create(false);
636	660		// создаем событие
637	661		WaitForB:=RTLEventCreate;
638	662		while not Application.Terminated do begin
639	663		// ждем бесконечно (пока B не разбудит A)
640	664		RtlEventWaitFor(WaitForB);
641	665		writeln('A: ThreadB.Counter='+IntToStr(Form1.ThreadB.Counter));
642	666		end;
643	667		end;
644	668
645	669		{ TThreadB }
646	670
647	671		procedure TThreadB.Execute;
648	672		var
649	673		i: Integer;
650	674		begin
651	675		Counter:=0;
652	676		while not Application.Terminated do begin
653	677		// B: Работает ...
654	678		Sleep(1500);
655	679		inc(Counter);
656	680		// будим A
657	681		RtlEventSetEvent(Form1.ThreadA.WaitForB);
658	682		end;
659	683		end;
660	684		```
661	685
662	686		Примечание: RtlEventSetEvent может быть вызвана перед RtlEventWaitFor. Тогда RtlEventWaitFor будет немедленно завершён (return). Используйте RTLeventResetEvent чтобы очистить флаг.
663	687
664	688		## Fork (порождение)
665	689
666	690		При порождении в многопоточном приложении, следует знать, что любые потоки, созданные и запущенные ПЕРЕД вызовом fork (или fpFork), НЕ будут запущены в дочернем процессе. Как заявлено в справочной странице fork(), невозможно определить состояние любых потоков, которые были запущены перед вызовом fork().
667	691
668	692		Если есть какие-либо потоки, инициализированные перед вызовом (включая секцию инициализации), они не будут работать.
669	693
670	694		## Параллельные процедуры/циклы
671	695
672	696		Особый случай работы много поточности во время выполнения кода смотрите [[Parallel procedures/ru\|здесь]].
673	697
674	698		## Распределённые вычисления
675	699
676	700		Следующим шагом после многопоточности является запуск потоков на различных машинах.
677	701
678	702		- Вы можете использовать один из TCP компонентов, таких как synapse, lnet или indy для связи. Это даст Вам наибольшую гибкость и, в основном, используется для слабо связанных Клиент / Серверных приложений.
679	703		- Вы можете использовать библиотеки передач сообщений, таких как [[MPICH]], которые используются для высокопроизводительных вычислений (HPC, High Performance Computing) в кластерах.
680	704
681	705		## Внешние потоки
682	706
683	707		Чтобы система потоков Free Pascal работала должным образом, каждый вновь созданный поток FPC должен быть инициализирован (точнее, исключение, система ввода-вывода и система threadvar для каждого потока должны быть инициализированы для работы потоков и кучи). Для вас это делается полностью автоматически, если вы используете BeginThread (или косвенно, используя класс TThread). Однако если вы используете потоки, которые были созданы без BeginThread (то есть внешние потоки), может потребоваться дополнительная работа (в настоящее время). Внешние потоки также включают те, которые были созданы во внешних библиотеках Cи (.DLL/.so).
684	708
685	709		Что следует учитывать при использовании внешних потоков (возможно не понадобится во всех или будущих версиях компилятора):
686	710
687	711		- Не используйте внешние потоки вообще - используйте потоки FPC. Если вы можете получить контроль над тем, как создается поток, создайте его самостоятельно с помощью BeginThread.
688	712
689	713		Если соглашение о вызовах не подходит (например, если вашей исходной функции потока требуется соглашение о вызовах cdecl, но BeginThread требует соглашения Паскаля), создайте запись, сохраните в ней исходную требуемую функцию потока и вызовите эту функцию в вашей паскалевской функции потока:
690	714
691	715		``` pascal
692	716		type
693	717		TCdeclThreadFunc = function (user_data:Pointer):Pointer;cdecl;
694	718
695	719		PCdeclThreadFuncData = ^TCdeclThreadFuncData;
696	720		TCdeclThreadFuncData = record
697	721		Func: TCdeclThreadFunc; //функция cdecl
698	722		Data: Pointer; //исходные данные
699	723		end;
700	724
701	725		// Паскалевский поток вызывает функцию cdecl
702	726		function C2P_Translator(FuncData: pointer) : ptrint;
703	727		var
704	728		ThreadData: TCdeclThreadFuncData;
705	729		begin
706	730		ThreadData := PCdeclThreadFuncData(FuncData)^;
707	731		Result := ptrint(ThreadData.Func(ThreadData.Data));
708	732		end;
709	733
710	734		procedure CreatePascalThread;
711	735		var
712	736		ThreadData: PCdeclThreadFuncData;
713	737		begin
714	738		New(ThreadData);
715	739		// это желаемая функция потока cdecl
716	740		ThreadData^.Func := func;
717	741		ThreadData^.Data := user_data;
718	742		// это создаст поток Паскаля
719	743		BeginThread(@C2P_Translator, ThreadData );
720	744		end;
721	745		```
722	746
723	747		- Инициализируйте систему потоков FPC, создав фиктивный поток. Если вы не создадите поток Pascal в своем приложении, система потоков не будет инициализирована (и, следовательно, потоки не будут работать и, следовательно, куча не будет работать правильно).
724	748
725	749		``` pascal
726	750		type
727	751		tc = class(tthread)
728	752		procedure execute;override;
729	753		end;
730	754
731	755		procedure tc.execute;
732	756		begin
733	757		end;
734	758
735	759		{ main program }
736	760		begin
737	761		{ инициализация системы потоков}
738	762		with tc.create(false) do
739	763		begin
740	764		waitfor;
741	765		free;
742	766		end;
743	767		{ ... ваш последующий код }
744	768		end.
745	769		```
746	770
747	771		> Note: После инициализации системы потоков среда выполнения может установить для системной переменной IsMultiThread значение true, которое используется подпрограммами FPC для выполнения блокировок здесь и там. Вы не должны устанавливать значение этой переменной вручную.
748	772
749	773		- Если по какой-то причине у вас это не работает, попробуйте этот код в функции внешнего потока:
750	774
751	775		``` pascal
752	776		function ExternalThread(param: Pointer): LongInt; stdcall;
753	777		var
754	778		tm: TThreadManager;
755	779		begin
756	780		GetThreadManager(tm);
757	781		tm.AllocateThreadVars;
758	782		InitThread(1000000); // отрегулируйте начальный размер стека здесь
759	783
760	784		{ делаем что-то в потоке здесь ... }
761	785
762	786		Result:=0;
763	787		end;
764	788		```
765	789
766	790		### Идентификация внешних потоков
767	791
768	792		Иногда вы даже не знаете, приходится ли вам иметь дело с внешними потоками (например, если какая-то библиотека Cи выполняет обратный вызов). Этот алгоритм может помочь понять это:
769	793
770	794		1\. Спрашиваем у ОС идентификатор текущего потока при запуске вашего приложения
771	795
772	796		``` pascal
773	797		GetCurrentThreadID() //windows;
774	798		GetThreadID() //Darwin/macOS;
775	799		TThreadID(pthread_self) //Linux;
776	800		```
777	801
778	802		2\. Спрашиваем еще раз идентификатор текущего потока внутри функции потока и сравниваем его с результатом шага 1.
779	803
780	804		### Откажитесь от использования временных функций
781	805
782	806		``` pascal
783	807		ThreadSwitch()
784	808		```
785	809
786	810		> Note: Не используйте виндовый трюк со [Sleep(0)](https://www.freepascal.org/docs-html/rtl/sysutils/sleep.html), так как это будет работать не на всех платформах.
787	811
788	812		## См. также
789	813
790	814		- [[Streaming components\|Компоненты потоковой (stream) передачи данных]]
791	815		- [[Manager Worker Threads System]]
792	816		- [[Example of multi-threaded application: array of threads]]
793	817		- [[Parallel procedures]]
794	818		- [[Main Loop Hooks]]
795	819		- [[Asynchronous Calls]]
796	820		- [Mutlithreading - The Delphi way](http://nickhodges.com/MultiThreadingInDelphi/ToC.html)
797	821
798	822		---
799	823		From the Free Pascal wiki, page "Multithreaded Application Tutorial/ru", as it stood on 2022-01-27 after a change by Alextp, 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