Multithreaded Application Tutorial/ru: what changed

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