Cleydson Silva

Parte 1 - Thread? O que é isso? Pra que isso?

Criar threads e usa-las não é uma tarefa complicada, porém o uso deste recurso introduz algumas dificuldades que não são enfrentadas pelo programador quando o mesmo utiliza a programação seqüencial.

Dizer que um programa é multithread é o mesmo que dizer que este programa possui vários pontos de execução, sendo um ponto para cada thread. Pra facilitar a compreensão é como se existisse um processador para cada thread, assim, ao criar uma thread você pode imaginar-se instanciando um novo processador para fazer o trabalho que você está dando para aquela thread fazer.

Eu acredito muito que o leitor não possui um super computador com dezenas de processadores, sendo assim, melhor manter o exemplo acima apenas para fins de compreensão do que realmente é uma thread ok?(Isso foi apenas um momento auto-ajuda, afinal de contas auto-ajuda vende muito mais que livros de informática. :D)

Na verdade o Sistema Operacional com seu algoritmo de escalonamento de processos, pede ao processador para fazer uma pequena parte do trabalho de cada vez e trocando de uma thread para outra e de um processo para outro tão rapidamente que temos a impressão de possuir vários processadores. Na verdade todo o processamento é feito em cima das threads, todo processo tem pelo menos uma thread, sendo assim,quando digo que o processador troca de um processo para outro é simplesmente para lembrar-lhe que temos threads de outros processos sendo executados o tempo todo.

Podemos dizer que os processos com suas respectivas threads concorrem ao processador e por essa e por outras o termo concorrência é tão usado ao se falar de threads.

Mas por que usar multithreads? Para que concorrência?

Caso você tenha um micro ou um servidor multiprocessado em mente já deve ter surgido imediatamente em sua cabeça a idéia de usar os recursos dos vários processadores que possui, afinal de contas para que tanto processador se não para aproveitar os mesmos.

Outra coisa seria utilizar as threads para trabalhar com dispositivos lentos (comparados ao nosso nobre processador) como impressoras, rede, discos e outros. Assim nossa thread vai fazer esse serviço de esperar o retorno dos nossos dispositivos “lesmas” enquanto nosso programa principal faz coisas mais importantes.

Agora, uma coisa é certa, a razão é sempre dos usuários. Mediante isso por que não pensar neles? Então por que deixar aquela tela travada para que o coitado fique abrindo o gerenciador de tarefas e matando o malvado processo que teima em travar todas as vezes que ele pede a geração de um determinado relatório ou uma consulta um pouco mais rebuscada, ou coisa do tipo? Neste caso a thread seria uma aliada. Ela iria trabalhar na consulta e a interface gráfica não seria substituída por uma tela branca travada e sem vida.

Um caso um pouco mais raro para a grande maioria dos desenvolvedores seria o uso na construção de uma aplicação distribuída. Imagine-se criando o seu próprio IIS, receber as requisições do usuário e então criar uma thread para cada requisição e deixa-la atende-lo. Obs.: Dei um exemplo extremamente simplista do trabalho do IIS, meramente ilustrativo.

Então é mais ou menos isso, sei que fui simplista, mas... pra que complicar? O objetivo foi entender o conceito. Logo virei com a segunda parte dessa conversa sobre threads. Como cria-las e controla-las.

Comentários e críticas são muito bem vindas.

Abraços!

//Cleydson