Otimize suas aplicações usando Threads

Salve amigos do PTI!

Bem, serei direto. Thread pra quem não conhece é um stream independente a qual implica em conjunto de instruções que rodam em paralelo. Existem diversas situações onde é extremamente necessário o uso de Threads como, por exemplo, situações onde a UI deve ser responsiva enquanto o servidor não responde, ou ainda em situações que requerem uma espera de recursos, como uso de arquivos ou um fetch do banco de dados.

Outra grande utilização é para threads que necessitam altíssima performance com cálculos matématicos. O motivo que venho a escrever este artigo, é para alertar a todos do mal uso de Threads. Vejo uma série de práticas mal formuladas e gostaria de compartilhar com vocês algumas dicas. Lembrando que estas dicas são mais voltadas a plataformas Desktop e servem para qualquer programador que faz target a windows e usa suas API’s, seja programado em delphi, vb, c, c++, java, c# etc..

  1. Evite criar Threads sem motivos aparentes. Um programa com um número alto de threads sobrecarrega o escalonador que ficará mais tempo trocando a linha de execução do que realizando o processamento propriamente dito.
  2. Evite de mudar a prioridade da threads. Isso é tarefa do sistema operacional, é ele que deve ditar o time slice de processamento. Com raras exceções, troque a prioridade da thread, mas depois retorna a sua opção default.
  3. Evite usar objetos Kernel (Mutex, Semaphore), com exceção da necessidade de uso de cross-processing messages, ou seja, quando as threads precisam conversar entre processos diferentes. (Lembrando que as threads são criadas “dentro” dos processos e que compartilham a pilha de memória, mas não conversam entre processos, a não ser que Kernel Objects sejam usados)
  4. Evite o uso de Foreground Threads. OH MY GOD, WHAT THE HELL IS THAT?! Foreground threads são as threads que continuam a executar quando a “main” thread termina. Um exemplo claro disso é o Outlook, que continua a rodar a thread de organizar a agenda mesmo quando o programa é fechado. Uma alternativa para isto é utilizar background threads, que finalizam a execução assim que a main thread termina. Exemplo: Spell-Checker do Word, que realmente não faz sentido continuar a execução após o usuário fechar o winword.exe.

Seja qual for a linguagem, ou qual for a API que vocês utilizarem, tomem atenção nestas dicas. Eu garanto pra vocês que o programa rodará mais rápido e que ações inusitadas ocorrerão com menos frequência 😉

Plante uma árvore 😉

Forte abraço.

Marcelo Bernart Schmidt

Mais artigos deste autor »

Programador .NET certificado MCP, MCTS F2.0, MCTS F3.5 e MCTS W2.0 nas linguagens VB.Net e C#.Net. Tem como hobbie ministrar cursos de programação em C# e orientação a objeto. O pai de Marcelo gostaria que ele fosse fazendeiro, fato ao qual não se concretizou. Marcelo ainda sente remorso do conselho do pai ao ver um programa com problemas de compilação.


2 Comentários

Genilto
2

Muuito bom artigo.
Eu sempre me reneguei a usar threads, talvez por que a ferramenta / linguagem que eu mais tenho conhecimento e que mais utilizo (forms/plsql) não possuam esses recursos. 🙂
Mas essa não é a questão, também porque isso não é exatamente o foco dessas ferramentas, hoje, e também se tiver que rodar alguma coisa a gente submete um processo concorrente, heheeh, quem conhecer do Oracle EBS sabe do que eu to falando.
Enfim, esses dias comecei a programar C# com um amigo fodão, acho que o nome dele era Marcelo Schimidt (sobrenome eu sempre erro), e realmente, Threads para aplicações Desktop são excenciais, claro, quando necessárias.
Parabéns novamente pelo artigo, grande abraço!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!