Multithreaded Application Tutorial/pt: what changed

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

Old	New		Line
1	1		## Introdução
2	2
3	3		Esta página irá tentar explicar com escrever e debugar uma aplicação multi-tarefa(multithread) com Free Pascal e Lazarus.
4	4
5	5		Uma aplicação multi-tarefa(multithread) é uma que cria duas ou mais tarefas em execução que trabalham ao mesmo tempo.
6	6
7	7		Se você é novo em multi-tarefa, por favor leia o parágrafo "O que você necessita para multi-tarefa ?" para descobrir, se você realmente necessita disto. Você pode se salvar de um monte de dores de cabeça.
8	8
9	9		Uma das tarefas é chamada de tarefa princípal. A Tarefa Princípal é criada pelo sistema operacional, cada vez que nossa aplicação inicia. A Tarefa Principal deve ter somente tarefa que atualiza os componentes que faz interfaces com o usuário(senão, a aplicação pode cair).
10	10
11	11		A principal idéia é que a aplicação pode fazer algum processamento em plano de fundo(background - numa segunda tarefa) enquando o usuário pode continuar seu trabalho (usando a tarefa principal).
12	12
13	13		Outro uso das tarefas é somente para ter uma melhor resposta da aplicação. Se você cria uma aplicação, e quando o usuário pressiona um botão, a aplicação inicia o processamento (um grande trabalho) ... e enquanto processando, a tela para de responder, e dá ao usuário a impressão de que a aplicação está morta, que não é legal. Se o grande trabalho é executado numa segunda tarefa, a aplicação mantém-se respondendo(sempre) como se estisse inativa. Neste caso é uma boa idéia, antes iniciando a tarefa, para disabilitar os botões da janela para evitar o usuário iniciar mais que uma tarefa por trabalho.
14	14
15	15		Outro uso, é para criar uma aplicação servidora(server application) que é abilitada para responder a vários clientes ao mesmo tempo.
16	16
17	17		## Você necessita de multi-tarefa?
18	18
19	19		Se você é um novato em multi-tarefa e quer somente fazer sua aplicação com melhor tempo de resposta enquanto sua aplicação processa grandes trabalhos, então multi-tarefa pode não ser, o que você está procurando.
20	20
21	21		Aplicações multi-tarefa sempre tem pesados debugs e eles são cada vez mais complexos. E em muitos casos você não precisa de multi-tarefa. Uma simples tarefa é o suficiente.
22	22
23	23		Multi-tarefa somente é necessário para:
24	24
25	25		- bloquear handles, como comunicação na rede
26	26		- usando múltiplos processadores de uma vez
27	27		- algoritmos e chamadas de bibliotecas, que não podem ser separadas em pequenas partes.
28	28
29	29		## A classe TThread
30	30
31	31		Os exemplos a seguir podem ser encontrados no diretório examples/multithreading/.
32	32
33	33		Para criar um aplicação multi-tarefa, a maneira mais fácil e usando a classe TThread. Esta classe permite a criação de uma thread adicional (ao lado da thread principal) de uma maneira simples. Normalmente você é obrigado a substituir apenas dois métodos: o construtor Create, e o método Execute. No construtor, você vai prepara a thread para funcionar. Você vai definir os valores iniciais das variáveis ou propriedades que você precisa. O construtor original da TThread requer um parâmetro chamado Suspended. Como você pode esperar, o ajuste Suspended = True impedirá que a thread execute automaticamente após a criação. Se Suspended = False, a thread irá executar logo após a criação. Se a thread é criada com Suspended = True, então ele será executado apenas depois que o método Resume for chamado.
34	34
35	35		A partir da versão 2.0.1 do FPC, TThread.Create tem um parâmetro implícito para o tamanho da pilha. Agora você pode alterar o tamanho predefinido de cada pilha, para cada thread que você criar, se você precisar. Procedimentos de chamadas recursivas é um bom exemplo. Se você não especificar o parâmetro de tamanho da pilha, o tamanho padrão da pilha do OS será usado.
36	36
37	37		Na substituição do método Execute, você escreverá o código que irá funcionar na thread.
38	38
39	39		A classe TThread tem uma importante propriedade: Terminated : boolean; Se a thread tem um loop ( isto é típico), o loop deve ser terminado quando Terminated for True (este tem valor False porpadrão). Por cada passagem, o valor do Terminated deve ser verificado e, se for True, então o loop deve ser encerrado tão rapidamente como é apropriado, após alguma limpeza necessária. Tenha em mente que o método Terminate não faz nada por padrão: o método Execute deve explicitamente implementar o suporte para ele finalizar o seu trabalho.
40	40
41	41		Como já explicamos anteriormente, a thread não deve interagir com componentes visuais. Atualizações para componentes visíveis deve ser feita dentro do contexto da thread principal. Para fazer isto, existe um método em TThread chamado Synchronize. Synchronize requer um método (este não leva nenhum parâmetro) como um argumento. Quando você chamar esse método através Synchronize(@MyMethod) a execução do thread será pausada, o código de MyMethod funcionará na thread principal, e a execução da thread será recomeçada então. O funcionamento exato de Synchronize depende da plataforma, mas basicamente é isto: afixa uma mensagem na fila de mensagem principal e vai dormir. Eventualmente a thread principal processa a mensagem e chama MyMethod. Desta forma MyMethod é chamado sem contexto, que não significa que seja durante um evento do mouse ou durante o evento Paint, mas depois. Após a thread principal ter executado MyMethod, desperta e processa a próxima mensagem. A thread então continua.
42	42
43	43		Há uma outra propriedade importante de TThread: FreeOnTerminate. Se esta propriedade é True, o objeto da thread é automaticamente liberado quando a execução da thread (método Execute) terminar. Se não a aplicação precisará ser liberada manualmente.
44	44
45	45		Exemplo:
46	46
47	47		``` pascal
48	48
49	49		Type
50	50		TMyThread = class(TThread)
51	51		private
52	52		fStatusText : string;
53	53		procedure ShowStatus;
54	54		protected
55	55		procedure Execute; override;
56	56		public
57	57		Constructor Create(CreateSuspended : boolean);
58	58		end;
59	59
60	60		constructor TMyThread.Create(CreateSuspended : boolean);
61	61		begin
62	62		FreeOnTerminate := True;
63	63		inherited Create(CreateSuspended);
64	64		end;
65	65
66	66		procedure TMyThread.ShowStatus;
67	67		// this method is executed by the mainthread and can therefore access all GUI elements.
68	68		begin
69	69		Form1.Caption := fStatusText;
70	70		end;
71	71
72	72		procedure TMyThread.Execute;
73	73		var
74	74		newStatus : string;
75	75		begin
76	76		fStatusText := 'TMyThread Starting...';
77	77		Synchronize(@Showstatus);
78	78		fStatusText := 'TMyThread Running...';
79	79		while (not Terminated) and ([any condition required]) do
80	80		begin
81	81		...
82	82		[here goes the code of the main thread loop]
83	83		...
84	84		if NewStatus <> fStatusText then
85	85		begin
86	86		fStatusText := newStatus;
87	87		Synchronize(@Showstatus);
88	88		end;
89	89		end;
90	90		end;
91	91		```
92	92
93	93		Na aplicação:
94	94
95	95		``` pascal
96	96
97	97		var
98	98		MyThread : TMyThread;
99	99		begin
100	100		MyThread := TMyThread.Create(True); // This way it doesn't start automatically
101	101		...
102	102		[Here the code initialises anything required before the threads starts executing]
103	103		...
104	104		MyThread.Resume;
105	105		end;
106	106		```
107	107
108	108		Se você quer fazer sua aplicação mais flexível, você pode criar um evento para o thread; Desta forma o seu método sincronizado não será fortemente acoplado com um formulário ou classe específico: você pode anexar os ouvintes de eventos da thread.
109	109
110	110		Aqui está um exemplo:
111	111
112	112		``` pascal
113	113
114	114		Type
115	115		TShowStatusEvent = procedure(Status: String) of Object;
116	116
117	117		TMyThread = class(TThread)
118	118		private
119	119		fStatusText : string;
120	120		FOnShowStatus: TShowStatusEvent;
121	121		procedure ShowStatus;
122	122		protected
123	123		procedure Execute; override;
124	124		public
125	125		Constructor Create(CreateSuspended : boolean);
126	126		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
127	127		end;
128	128
129	129		constructor TMyThread.Create(CreateSuspended : boolean);
130	130		begin
131	131		FreeOnTerminate := True;
132	132		inherited Create(CreateSuspended);
133	133		end;
134	134
135	135		procedure TMyThread.ShowStatus;
136	136		// this method is executed by the mainthread and can therefore access all GUI elements.
137	137		begin
138	138		if Assigned(FOnShowStatus) then
139	139		begin
140	140		FOnShowStatus(fStatusText);
141	141		end;
142	142		end;
143	143
144	144		procedure TMyThread.Execute;
145	145		var
146	146		newStatus : string;
147	147		begin
148	148		fStatusText := 'TMyThread Starting...';
149	149		Synchronize(@Showstatus);
150	150		fStatusText := 'TMyThread Running...';
151	151		while (not Terminated) and ([any condition required]) do
152	152		begin
153	153		...
154	154		[here goes the code of the main thread loop]
155	155		...
156	156		if NewStatus <> fStatusText then
157	157		begin
158	158		fStatusText := newStatus;
159	159		Synchronize(@Showstatus);
160	160		end;
161	161		end;
162	162		end;
163	163		```
164	164
165	165		Na Aplicação,
166	166
167	167		``` pascal
168	168
169	169		Type
170	170		TForm1 = class(TForm)
171	171		Button1: TButton;
172	172		Label1: TLabel;
173	173		procedure FormCreate(Sender: TObject);
174	174		procedure FormDestroy(Sender: TObject);
175	175		private
176	176		{ private declarations }
177	177		MyThread: TMyThread;
178	178		procedure ShowStatus(Status: string);
179	179		public
180	180		{ public declarations }
181	181		end;
182	182
183	183		procedure TForm1.FormCreate(Sender: TObject);
184	184		begin
185	185		inherited;
186	186		MyThread := TMyThread.Create(true);
187	187		MyThread.OnShowStatus := @ShowStatus;
188	188		end;
189	189
190	190		procedure TForm1.FormDestroy(Sender: TObject);
191	191		begin
192	192		MyThread.Terminate;
193	193		MyThread.Free;
194	194		inherited;
195	195		end;
196	196
197	197		procedure TForm1.Button1Click(Sender: TObject);
198	198		begin
199	199		MyThread.Resume;
200	200		end;
201	201
202	202		procedure TForm1.ShowStatus(Status: string);
203	203		begin
204	204		Label1.Caption := Status;
205	205		end;
206	206		```
207	207
208	208		## Coisas para ter cuidados especiais
209	209
210	210		No Windows há um possível problema quando se usa threads e você usar a opção -Ct (checagem de pilha). Por razões não tão claras a verificação de pilhas será disparada em qualquer TThread.Create, se você usar o padrão de tamanho da pilha. A única alternativa no momento é simplesmente não usar a opção -Ct. Nota-se que não causa uma exceção no segmento principal, mas no recém-criado. É como se a thread não tivesse iniciado.
211	211
212	212		Um bom código para verificar esta e outras exceções que podem ocorrer na criação da threads é:
213	213
214	214		``` pascal
215	215		MyThread:=TThread.Create(False);
216	216		if Assigned(MyThread.FatalException) then
217	217		raise MyThread.FatalException;
218	218		```
219	219
220	220		Esse código vai garantir que qualquer exceção que ocorra durante a criação da thread seja lançada em seu segmento principal.
221	221
222	222		## Unidades necessárias para uma aplicação multi-tarefa
223	223
224	224		Você não precisa de qualquer unidade especial para funcionar no Windows. Contudo com Linux, Mac OS X e FreeBSD, você vai precisar da unidade cthreads e deve ser a primeira unidade do projeto. (a unidade do programa, .lpr)! Assim, o código do aplicativo Lazaro deve ser parecido:
225	225
226	226		``` pascal
227	227		program MyMultiThreadedProgram;
228	228		{$mode objfpc}{$H+}
229	229		uses
230	230		{$ifdef unix}
231	231		cthreads,
232	232		cmem, // the c memory manager is on some systems much faster for multi-threading
233	233		{$endif}
234	234		Interfaces, // this includes the LCL widgetset
235	235		Forms
236	236		{ add your units here },
237	237		```
238	238
239	239		Se você esquecer isso, você irá obter este erro na inicialização:
240	240
241		-	`This binary has no thread support compiled in.`\
242		-	~~`Recompile the application with a thread-driver in the program uses clause before other units using thread.`~~
	241	+	``` pascal
	242	+	This binary has no thread support compiled in.
	243	+	Recompile the application with a thread-driver in the program uses clause before other units using thread.
	244	+	```
243	245
244	246		Pacotes que utilizam multi-tarefa devem adicionar o indicador -dUseCThreads nas opções de uso personalizado. Abra o pacote, e no editor vá em Options \> Usage \> Custom e adicione -dUseCThreads. Isto irá definir este indicador para todos os projetos e pacotes usando este pacote, incluindo a IDE. A IDE e todas as novas aplicações criadas já terá o seguinte código incluído no arquivo .lpr:
245	247
246	248		``` pascal
247	249		uses
248	250		{$IFDEF UNIX}{$IFDEF UseCThreads}
249	251		cthreads,
250	252		cmem, // the c memory manager is on some systems much faster for multi-threading
251	253		{$ENDIF}{$ENDIF}
252	254		```
253	255
254	256		## Suporte para Sistema de Multi Processo Simétrico (SMP)
255	257
256	258		A boa notícia é que se sua aplicação trabalhar com suporte a multi-tarefa desta forma, já terá SMP habilitado!
257	259
258	260		## Depuração de aplicações multi-tarefa com Lazaro
259	261
260	262		A depuração no Lazarus não está ainda totalmente funcional.
261	263
262	264		### Depuração de saída
263	265
264	266		Em um aplicativo de thread simples, você pode simplesmente escrever console/terminal/ou qualquer um e a ordem das linhas é a mesma que foram escritas. Em aplicações multi-tarefa as coisas são mais complicadas. Se duas threads estão escrevendo, dizem que uma linha é escrita pela thread A antes de uma thread B, as linhas não são necessariamente escritas nessa ordem. Pode acontecer, de uma thread escrever sua saída, enquanto outra thread está escrevendo uma linha.
265	267
266	268		A unidade LCLProc contem várias funções, para deixar cada thread escrever o seu próprio arquivo log.
267	269
268	270		``` pascal
269	271		procedure DbgOutThreadLog(const Msg: string); overload;
270	272		procedure DebuglnThreadLog(const Msg: string); overload;
271	273		procedure DebuglnThreadLog(Args: array of const); overload;
272	274		procedure DebuglnThreadLog; overload;
273	275		```
274	276
275	277		Por Exemplo: Em vez de writeln('Algum texto ',123); use DebuglnThreadLog(\['Some text ',123\]); Isto irá adicionar uma linha 'Algum texto 123' em Log\<PID\>.txt, onde \<PID\> e o ID do processo da thread corrente.
276	278
277	279		É uma boa idéia remover o arquivo de log antes de cada execução:
278	280
279		-	~~`rm -f Log* && ./project1`~~
	281	+	```text
	282	+	rm -f Log* && ./project1
	283	+	```
280	284
281	285		### Linux
282	286
283	287		Se você tentar depurar um aplicativo multi-tarefa em Linux, você terá um grande problema: o servidor X irá travar. Não se sabe como resolver isso corretamente, mas uma solução é:
284	288
285	289		Crie uma nova instância do X:
286	290
287		-	~~`X :1 &`~~
	291	+	```text
	292	+	X :1 &
	293	+	```
288	294
289	295		Será aberta uma nova seção X, e quando você mudar para a nova seção X (para retornar ao que você estava trabalhando pressione CTRL+ALT+F7), você será capaz de voltar para a nova tela gráfica usando CTRL+ALT+F8 (Se essa combinação não funcionar, tente com CTRL+ALT+F2 ...isto se estiver trabalhado com Slackware)
290	296
291	297		Então você poderia, se quiser, criar uma área de trabalho na seção X iniciada com:
292	298
293		-	~~`gnome-session --display=:1 &`~~
	299	+	```text
	300	+	gnome-session --display=:1 &
	301	+	```
294	302
295	303		Então, no Lazaro, nos parâmetros de execução do projeto, verifique “Use display” e digite :1. Agora a aplicação será executada no segundo servidor X e depurada no primeiro. Isto foi testado com Free Pascal 2.0 e Lazarus 0.9.10 no Windows e Linux.
296	304
297	305		------------------------------------------------------------------------
298	306
299	307		Em vez de criar uma nova seção X, pode-se usar Xnest. Xnest é uma seção X em uma janela. Usando isto o servidor X não travará durante a depuração das threads, e é muito mais fácil de depurar sem ter que alternar entre os terminais o tempo todo.
300	308
301	309		A linha de comando para executar Xnest é
302	310
303		-	~~`Xnest :1 -ac`~~
	311	+	```text
	312	+	Xnest :1 -ac
	313	+	```
304	314
305	315		para criar uma seção X sobre :1, e desabilitar os controles de acesso.
306	316
307	317		## Widgetsets
308	318
309	319		As interfaces win32, GTK e a carbono suportam plenamente multi-tarefa. Isso significa que a classe TThreads, as seções críticas (TCriticalSection) e a sincronização (Synchronize) funcionarão.
310	320
311	321		## Seções críticas
312	322
313	323		Uma seção crítica é um objeto usado para certificar-se, de que alguma parte do código será executado apenas por uma thread de cada vez. Uma seção crítica precisa ser criada e inicializada antes de ser usada e deve ser liberado quando não for mais necessário.
314	324
315	325		As seções críticas são normalmente utilizados da seguinte maneira:
316	326
317	327		Adicione a unidade SyncObjs.
318	328
319	329		Declare a seção globalmente para todos as threads que devem ter acesso:
320	330
321	331		``` pascal
322	332		MyCriticalSection: TRTLCriticalSection;
323	333		```
324	334
325	335		Crie a seção:
326	336
327	337		``` pascal
328	338		InitializeCriticalSection(MyCriticalSection);
329	339		```
330	340
331	341		Execute alguma thread, fazendo algo que deve ser exclusivo
332	342
333	343		``` pascal
334	344		EnterCriticalSection(MyCriticalSection);
335	345		try
336	346		// access some variables, write files, send some network packets, etc
337	347		finally
338	348		LeaveCriticalSection(MyCriticalSection);
339	349		end;
340	350		```
341	351
342	352		Após ter terminado todas as threads, libere a seção crítica:
343	353
344	354		``` pascal
345	355		DeleteCriticalSection(MyCriticalSection);
346	356		```
347	357
348	358		Como alternativa, você pode usar um objeto TcriticalSection. A criação é feita pelo Inicialization, o método Enter é feita pelo EnterCriticalSection, o método Leave é feita pelo LeaveCriticalSection e a destruição do objeto é feita pelo deletion.
349	359
350	360		Por exemplo: 5 threads incrementando um contador. Veja lazarus/examples/multithreading/criticalsectionexample1.lpi
351	361
352	362		CUIDADO: Há dois conjuntos das 4 funções acima. Um Conjunto da RTL e outra da LCL. As funções da LCL estão definida nas unidade LCLIntf e LCLType. Ambos trabalham de forma parecida. Você pode usar os dois ao mesmo tempo na sua aplicação, mas você não deve usar uma função RTL com uma seção crítica LCL, e vice versa.
353	363
354	364		## Compartilhamento de variáveis
355	365
356	366		Se algumas threads compartilharem uma variável, que é somente leitura, então não tem nada com que se preocupar. Mas se uma ou diversas threads escrevem na variável, então você deve se certificar de que somente uma thread por vez acessará a variável.
357	367
358	368		Por exemplo: 5 threads incrementando um contador: veja lazarus/examples/multithreading/criticalsectionexample1.lpi
359	369
360	370		## Esperando por outra thread
361	371
362	372		Se a thread A precisar de um resultado de outra thread B, ela deve esperar, até que B tenha terminado.
363	373
364	374		Importante: A thread principal nunca deve esperar por outra thread. Ao invez disso use Synchronize (veja acima).
365	375
366	376		Veja um exemplo: lazarus/examples/multithreading/waitforexample1.lpi
367	377
368	378		``` pascal
369	379
370	380		{ TThreadA }
371	381
372	382		procedure TThreadA.Execute;
373	383		begin
374	384		Form1.ThreadB:=TThreadB.Create(false);
375	385		// create event
376	386		WaitForB:=RTLEventCreate;
377	387		while not Application.Terminated do begin
378	388		// wait infinitely (until B wakes A)
379	389		RtlEventWaitFor(WaitForB);
380	390		writeln('A: ThreadB.Counter='+IntToStr(Form1.ThreadB.Counter));
381	391		end;
382	392		end;
383	393
384	394		{ TThreadB }
385	395
386	396		procedure TThreadB.Execute;
387	397		var
388	398		i: Integer;
389	399		begin
390	400		Counter:=0;
391	401		while not Application.Terminated do begin
392	402		// B: Working ...
393	403		Sleep(1500);
394	404		inc(Counter);
395	405		// wake A
396	406		RtlEventSetEvent(Form1.ThreadA.WaitForB);
397	407		end;
398	408		end;
399	409		```
400	410
401	411		Nota: RtlEventSetEvent pode ser chamado antes de RtlEventWaitFor. Então RtlEventWaitFor retornará imediatamente. Use RTLeventResetEvent para limpar um indicador.
402	412
403	413		## Fork
404	414
405	415		Quando replicamos uma aplicação mult-threaded, esteja ciente de que qualquer thread criada e executada ANTES de realizar a replica, NÃO será executado no processo filho. Como indicado no manual do fork(). Todas as threads que estavam sendo executadas antes da chamada da replica, seu estado será indefinido.
406	416
407	417		Portanto, esteja ciente de qualquer thread inicializada antes da chamada (incluindo na seção de inicialização). Eles não irão funcionar.
408	418
409	419		## Processos paralelos/laços
410	420
411	421		Um caso especial de multi-tarefa e executando um procedimento único em paralelo. veja [[Parallel procedures]].
412	422
413	423		## Computação distribuída
414	424
415	425		Os próximos maiores passos, após programas multi-tarefa, é executar os segmentos em várias máquinas.
416	426
417	427		- Você pode usar uma das suítes do TCP como sinapse, LNET ou Indy para comunicações. Isto lhe dá a máxima flexibilidade e é largamente utilizado para aplicações cliente / servidor com conexões rápidas.
418	428
419	429		- Você pode usar bibliotecas de envio de mensagens, como MPICH, que são utilizados para HPC (High Performance Computing) em clusters.
420	430
421	431		---
422	432		From the Free Pascal wiki, page "Multithreaded Application Tutorial/pt", as it stood on 2020-02-20 after a change by Trev, 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