Clique aqui para ler todos os artigos desta edição
Uma introdução ao uso de Threads – Parte I
Por Roberto Lopes
Leia a Parte II.
O Windows, por ser um sistema operacional multitarefa, é capaz de executar várias tarefas ao mesmo tempo. Isso quer dizer que você pode, por exemplo, escrever um documento no Word enquanto faz o backup de sua máquina, tudo ao mesmo tempo. Se você nunca desenvolveu em um sistema operacional não multitarefa (DOS, por exemplo), pode estar achando isso óbvio, mas saiba que não é. No DOS, por exemplo, não é possível executar dois programas ao mesmo tempo (escrever um arquivo em um editor de textos enquanto faz o backup da sua máquina).
Na prática, o DOS não é capaz de executar mais de um programa ao mesmo tempo justamente por não poder gerenciar mais de uma linha de execução ao mesmo tempo, lembrando que thread vem do termo “linha de execução” (Thread of execution em inglês).
Você não vai precisar criar novas threads em todos os seus aplicativos, mas dependendo do tipo de aplicativo que você esteja escrevendo, o uso de threads pode ser altamente recomendável. Neste artigo vou explicar na prática, como funciona e como criar linhas de processamento em um aplicativo.
Entendendo como uma Thread funciona
Um processador não é capaz de processar mais de uma instrução ao mesmo tempo, isso é, se ele tem duas instruções para executar em sua fila, ele vai executar primeiro uma e depois a outra. Porém, ele é capaz de trabalhar com mais de uma linha de execução ao mesmo tempo. Cada linha de execução possui sua própria fila de instruções para serem executadas. O processador então executa uma instrução de cada linha de execução consecutivamente, fazendo com que o processador “pareça” estar executando mais de uma instrução ao mesmo tempo.
Um exemplo. Digamos que criamos um aplicativo que executa dois processamentos simultaneamente, chamados A e B. Digamos ainda que ambos possuem em cada um, cinco instruções a serem executadas e essas instruções tenham um número seqüencial crescente (para o processo A seria: A1, A2, A3, A4 e A5. O processo B seria: B1, B2, B3, B4 e B5).
Veja na Figura 1 a representação gráfica do resultado desse processamento em um aplicativo não multitarefa.
Figura 1. Exemplo de processamento não multitarefa
No quadro Linhas de Execução, temos o aplicativo que possui os dois processos a serem executados. Note que apesar de serem dois processos, apenas uma linha de execução é utilizada entre o aplicativo e o processador, isso é, apenas a thread principal comunicou-se com o processador.
Já na Figura 2, temos a representação gráfica do processamento em um aplicativo multitarefa.
Figura 2. Exemplo de processamento multitarefa
No quadro Linhas de Execução, temos o aplicativo que possui os dois processos a serem executados. Porém nesse caso, não temos apenas uma thread comunicando-se com o processador, mas duas. Aqui tenho um detalhe a destacar. Observando o gráfico, veja que o primeiro processo faz uso da thread principal (não existe linha de execução diretamente entre o processo A e o processador) e o processo B é executado em uma segunda thread criada.
Note que na Figura 1, a segunda linha de processamento (B) somente começou a ser executada quando a primeira (A) foi concluída. Isso pode ser notado porque no quadro Resultado, primeiro todas as instruções do processo A são processadas e somente depois disso é que as instruções do processo B aparecem no resultado.
Já na Figura 2, veja que ambos os processos foram executados em paralelo, fazendo com que o processador concluísse as duas tarefas quase que simultaneamente. Nesse caso, no quadro Resultado, note que o resultado é alternado, isso é, uma instrução do processo A, uma do processo B e assim por diante.
Por isso, threads trazem inúmeros benefícios ao aplicativo, não apenas em performance, mas em flexibilidade e acessibilidade também. Lembre-se do primeiro exemplo que citei, fazer um backup enquanto escreve um documento no Word.
O .NET Framework, através do Managed Code e o namespace System.Threading, foi um grande presente da Microsoft para o desenvolvedor, pois transformou um processo complexo, difícil e perigoso em um processo muito mais acessível, seguro e simples.
A API Win32 (do Windows SDK), possui inúmeros recursos para a execução de threads diretamente no Windows (Unmanaged Code), mas qualquer desenvolvedor que já tenha usado esses recursos nessas condições, sabe que é um processo complexo e delicado.
Só pra citar um exemplo, lembre-se que todo e qualquer tipo de alocação de memória em Unmanaged Code, a liberação dessa após o uso é de total responsabilidade do executor. Desse modo, se um bug no seu código deixar de liberar a memória após o seu uso, essa ficará perdida, caracterizando um vazamento de memória (Memory Leak).
...
