2. Vantagens da programação concorrente. 2.1 Divisão de trabalho

Transcrição

1 Vantagens e desvantagens do paradigma da programação concorrente: análise de hardware e software Gabriel Giuliani Baú 1 1 Curso de Sistemas de Informação - Universidade Luterana do Brasil - ULBRA BR 287, Km 252, Trevo Maneco Pedroso - Boca do Monte - Cx. Postal CEP Santa Maria/RS gabriel.ulbra@gmail.com RESUMO Este artigo pretende mostrar as principais vantagens do uso do paradigma da programação concorrente no desenvolvimento de software e as desvantagens que levam à sua baixa utilização atualmente na comunidade dos desenvolvedores, que são a dificuldade de implementação e controle do código e a baixa disponibilidade de hardware necessário para um bom aproveitamento do paradigma. São mostrados exemplos de casos em que há um grande benefício no uso desse paradigma, e também exemplos de casos em que há desafios para superar ao utilizar esse paradigma. ABSTRACT This article intends to show the main advantages in using the concurrent programming paradigm in developing software and the main disadvantages that lead to it s low utilization in the developers community wich are the implementation difficulty and code control and the low necessary hardware availability for a good use of the paradigm. Case examples are shown where there is a great benefit in the use of this paradigms, as well as case examples where there are challenges to surpass to use this paradigm. 1. Introdução A programação concorrente é aquela que, divide a tarefa que um software, ou parte dele, necessita completar, em partes. O principal objetivo dessa divisão é a finalização em menor tempo das diversas tarefas ao utilizar de forma mais eficiente os recursos de hardware disponíveis. Não se deve confundir a programação concorrente com a computação paralela, pois apesar de serem relacionadas, a primeira possui foco na iteração entre as tarefas. Com o advento dos processadores com dois ou mais núcleos (cores) há um incentivo cada vez maior dos fabricantes de hardware para o desenvolvimento de softwares que utilizam à programação concorrente. Porém o número de softwares

2 desenvolvidos nesse paradigma é muito baixo e cresce pouco em comparação ao estruturado. As principais empresas desenvolvedoras de software estão adequando seus produtos a essa nova realidade do hardware, e tentando tirar proveito do paradigma, isso pode ser percebido nas comparações e testes realizados com as novas versões dos produtos dessas empresas, houve uma aceleração em aplicações de tratamento e edição de fotografias digitais, compactação e edição de filmes, até mesmo a compactação de arquivos está se beneficiando disso. Mas então porque mencionar a baixa utilização do paradigma? Na verdade as grandes empresas possuem orçamentos suficientes para fornecer o treinamento e as ferramentas necessárias aos desenvolvedores para que utilizem a concorrência nos programas. Já uma pequena empresa, que sobrevive do desenvolvimento de um número menor de produtos, não consegue custear o treinamento dos desenvolvedores e um possível e provável atraso no desenvolvimento de algum produto pela dificuldade que existe na manutenção e depuração do código. Ela precisa estar em dia com todos os projetos, pois corre o risco de não suportar a perda de clientes e lucros fundamentais para o seu bom andamento. Neste artigo mostro testes analisando a performance de softwares que utilizam concorrência, exemplos básicos de código e que a dificuldade no avanço do uso desse paradigma em larga escala se deve a dois principais problemas que são a manutenção e depuração do código. 2. Vantagens da programação concorrente 2.1 Divisão de trabalho Existem tarefas dentro do código de certos softwares que podem ser dividas entre dois ou mais processadores de um mesmo computador, um bom exemplo é a utilização dos novos processadores de núcleo duplo executando um programa reprodutor de filmes. Enquanto a imagem é processada em um deles, o som pode ser processado em outro. Isso traz um grande benefício, a divisão de trabalho, onde pode-se notar um menor uso da capacidade de cada um, o que possibilita a execução de outras tarefas do sistema operacional e até mesmo outros softwares que utilizem dois processadores porém não consumindo 100% deles. 2

3 Figura 1 Gerenciador de Tarefas do Windows XP Processamento de um filme, áudio em um núcleo, vídeo em outro. 2.2 Aumento de desempenho em uma tarefa importante Outras aplicações podem utilizar dois núcleos para diminuir o tempo de execução de certa tarefa considerada importante e que mereça ser realizada em menor tempo. Um bom exemplo é a compactação de um arquivo, pode-se obter em um cenário ideal, uma diminuição de 50% no tempo necessário para a compactação de um arquivo. A utilização dos dois núcleos será máxima e é possível que as tarefas menos importantes do sistema operacional e os outros programas que estavam em execução sofram uma queda de desempenho. [Citação] - FIGURA Além disso, quando temos um processador de núcleo único, as diversas tarefas que estão sendo executadas muitas vezes sem a intervenção do usuário, como carregamento e interpretação de drivers do sistema operacional, serviços de aplicativos e requisições de conexão de sites da internet podem consumir um tempo de processador precioso, impedindo um bom desempenho da tarefa principal para o usuário. Se utilizarmos um processador de núcleo duplo e se o sistema operacional, seus drivers e serviços de aplicativos forem programados utilizando o paradigma concorrente, pode-se utilizar apenas um dos núcleos para essas tarefas, enquanto o outro continua livre para processar a aplicação principal com um desempenho superior. 3

4 Figura 2 Gerenciador de tarefas Windows XP Uso total de todos os núcleos para o processamento de uma imagem tridimensional no menor tempo possível. 4

5 Figura 3 Software alternando a porcentagem de uso dos núcleos conforme os threads vão sendo iniciados ou finalizados. 3. Desvantagens da programação concorrente 3.1 Dificuldade de programação tratamento de threads Ao utilizar o paradigma concorrente, o programador poderá utilizar vários recursos, o mais conhecido são os threads (processos leves), que dividem o trabalho que necessita ser realizado em duas ou mais partes. Dessa forma o processador não necessita aguardar o término de uma instrução para iniciar outra como ocorre no paradigma estruturado clássico, pode-se iniciar no mínimo duas tarefas simultaneamente quando utilizamos um processador de núcleo duplo. Mas para a utilização desses threads é estritamente necessário um controle rigoroso dos componentes utilizados por ela, pois como estarão sendo executados dois ou mais processos que pertencem a uma mesma aplicação, corremos o risco de um comando de um thread requisitar acesso a uma região da memória que já está utilizada por outra. Isso causaria no pior caso uma interrupção repentina na execução do programa, podendo levar à perda de informações importantes contidas na memória de execução que ainda não haviam sido gravadas em um lugar definitivo. O grande empecilho na adoção da programação concorrente está no excesso de esforço necessário por parte do programador para acompanhar e controlar as modificações ou acessos que esses threads fazem ao longo do programa. Um método comum para o controle dos threads, é a Sincronização Condicional. 5

6 3.1.1 Sincronização Condicional Para que um thread não interfira em outro, usa-se dois tipos de sinal, o WAIT (espere) e o NOTIFY (sinal para prosseguir). Supondo uma situação onde dois threads possuam trecho de código que instrui para acessar uma mesma área de memória, o primeiro thread teria de emitir o sinal WAIT para a segunda, e assim que realizasse todas as operações necessárias com aquela área da memória, enviaria o NOTIFY para o segundo thread iniciar seu acesso. Isso seria a situação ideal. Porém não é assim que ocorre em algumas implementações do UNIX.² Dependendo da implementação pode haver uma perda de sinal entre os threads causando a não-execução de determinada tarefa por uma das threads, impactando todo o andamento da aplicação. Figura 3 Ilustração dos sinais de controle 3.2 Baixo suporte de hardware Os fabricantes de processadores para computadores pessoais estão lançando muitos modelos de núcleo duplo e até quádruplo no mercado atual. Mas isso não significa que haja uma grande demanda por eles ou que as pessoas estejam trocando todos os seus computadores por esses. Muitos desktops e notebooks são ainda vendidos com apenas um núcleo de processamento, pois os preços dos processadores de núcleo duplo são altos demais. E ainda não justificam a compra, pois os usuários finais dificilmente utilizam todo o potencial que eles proporcionam. Para utilizar um editor de texto, uma planilha eletrônica, escutar música e navegar na internet, pode-se utilizar um processador de apenas um núcleo sem maiores problemas. E isso deve permanecer assim por um bom tempo, pois até mesmo os novos sistemas operacionais que prometiam exigir tanto dos computadores que poderiam forçar o usuário a substituir o seu por um mais atualizado, não mostraram tanta exigência, houve um aumento no consumo de memória, mas nada proporcional ao aumento de utilização de capacidade de processamento. Sem hardware para utilizar o potencial dos softwares, fica mais difícil ainda a adoção da programação concorrente, já que não há uma demanda global. Essa demanda só deve realmente surgir quando novas tecnologias como o HD-DVD, Blue-Ray, e HDTV forem amplamente distribuídas até mesmo nos países em desenvolvimento. Esses padrões de multimídia utilizam muitos recursos de processamento, e são uma boa aplicação para o paradigma. 6

7 Figura 4 Gasto com processadores Single Core (Um núcleo) e Multicore (Vários núcleos) em 2005 e 2006 para uso em servidores A figura acima apresenta dados interessantes quanto à adoção da tecnologia de vários núcleos, percebemos que nos anos de 2005 e 2006 houve um rápido crescimento nas vendas de processadores de vários núcleos para servidores que utilizam o sistema operacional Unix, mas um crescimento não consistente nas outras plataformas. Se esse cenário se apresenta em um terreno onde os programas desenvolvidos com a concorrência como foco, não é animador, o que pensar do mercado global para o usuário final? 4.Conclusão Não existe a base de hardware instalada necessária hoje para alavancar o desenvolvimento em larga escala de sistemas concorrentes. Claro que é possível o desenvolvimento de software em paradigma concorrente para um processador com apenas um núcleo, porém não é aí que o paradigma é mais bem utilizado. Além disso, é necessário um maior grau de conhecimento e treinamento do desenvolvedor para chegar a bons resultados sem problemas de controle dos threads. As linguagens de programação oferecem bibliotecas e compiladores para o desenvolvimento, porém não há grande interesse na mudança de paradigma, ainda é difícil hoje encontrar pessoas que deixem as facilidades do paradigma estruturado. A programação concorrente exige tempo, investimento em treinamento, depuração e testes maiores, pois existem mais situações a prever e maiores possibilidades de erros ou conflitos nas aplicações devido à necessidade de sincronia perfeita entre os threads. Além disso, não há uma disseminação em larga escala de processadores de vários núcleos, a grande maioria dos computadores do mundo utiliza apenas um núcleo de processamento. Isso também desmotiva o desenvolvedor a mudar de paradigma, pois seu produto não será utilizado da maneira que foi projetada, ou não terá o mesmo desempenho. 7

8 Referências - URLs 2 Silva, Dilme Menezes (1999) Introdução à Programação Concorrente para a Internet Disponível em: Bits and pieces (mostly Lisp-related) that I collect from the ether. Acesso em 18 Jun Software in the TLP Era Acesso em 18 Jun Curso de Programação Concorrente. Acesso em 18 Jun Concurrent Programming. Acesso em 17 Jun Wikipedia - Concurrent computing. Acesso em 17 Jun Intel Ignites Quad-Core Era - Quad-Core Processors Bring Higher Performance and Lower Cost to Mainstream Computing Matthew Eastwood Kenneth Cayton, Abril Acesso em 18 Jun 2007 ftp://ftp.aw.com/cseng/authors/finkel/apld/finkel07.pdf - Concurrent Programming - Acesso em 18 Jun The Joys of Concurrent Programming Acesso em 16 Jun A Logic for Concurrent Programming: Safety Acesso em 16 Jun