Vantagens e desvantagens do paradigma da

programao concorrente: anlise de hardware e software

Gabriel Giuliani Ba1
1
Curso de Sistemas de Informao - Universidade Luterana do Brasil - ULBRA
BR 287, Km 252, Trevo Maneco Pedroso - Boca do Monte - Cx. Postal 21834 - CEP
97020-001 - Santa Maria/RS
gabriel.ulbra@gmail.com

RESUMO

Este artigo pretende mostrar as principais vantagens do uso do paradigma da

programao concorrente no desenvolvimento de software e as desvantagens
que levam sua baixa utilizao atualmente na comunidade dos
desenvolvedores, que so a dificuldade de implementao e controle do cdigo
e a baixa disponibilidade de hardware necessrio para um bom aproveitamento
do paradigma. So mostrados exemplos de casos em que h um grande
benefcio no uso desse paradigma, e tambm 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 its 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. Introduo

A programao concorrente aquela que, divide a tarefa que um software, ou

parte dele, necessita completar, em partes. O principal objetivo dessa diviso a
finalizao em menor tempo das diversas tarefas ao utilizar de forma mais eficiente os
recursos de hardware disponveis. No se deve confundir a programao concorrente
com a computao paralela, pois apesar de serem relacionadas, a primeira possui foco
na iterao entre as tarefas.
Com o advento dos processadores com dois ou mais ncleos (cores) h um
incentivo cada vez maior dos fabricantes de hardware para o desenvolvimento de
softwares que utilizam programao concorrente. Porm o nmero de softwares
desenvolvidos nesse paradigma muito baixo e cresce pouco em comparao ao
estruturado.
As principais empresas desenvolvedoras de software esto adequando seus
produtos a essa nova realidade do hardware, e tentando tirar proveito do paradigma, isso
pode ser percebido nas comparaes e testes realizados com as novas verses dos
produtos dessas empresas, houve uma acelerao em aplicaes de tratamento e edio
de fotografias digitais, compactao e edio de filmes, at mesmo a compactao de
arquivos est se beneficiando disso.
Mas ento porque mencionar a baixa utilizao do paradigma? Na verdade as
grandes empresas possuem oramentos suficientes para fornecer o treinamento e as
ferramentas necessrias aos desenvolvedores para que utilizem a concorrncia nos
programas. J uma pequena empresa, que sobrevive do desenvolvimento de um nmero
menor de produtos, no consegue custear o treinamento dos desenvolvedores e um
possvel e provvel atraso no desenvolvimento de algum produto pela dificuldade que
existe na manuteno e depurao do cdigo. Ela precisa estar em dia com todos os
projetos, pois corre o risco de no suportar a perda de clientes e lucros fundamentais
para o seu bom andamento.
Neste artigo mostro testes analisando a performance de softwares que utilizam
concorrncia, exemplos bsicos de cdigo e que a dificuldade no avano do uso desse
paradigma em larga escala se deve a dois principais problemas que so a manuteno e
depurao do cdigo.

2. Vantagens da programao concorrente

2.1 Diviso de trabalho

Existem tarefas dentro do cdigo de certos softwares que podem ser dividas entre dois
ou mais processadores de um mesmo computador, um bom exemplo a utilizao dos
novos processadores de ncleo 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 benefcio, a diviso de trabalho, onde pode-se notar um menor uso
da capacidade de cada um, o que possibilita a execuo de outras tarefas do sistema
operacional e at mesmo outros softwares que utilizem dois processadores porm no
consumindo 100% deles.

2
 Figura 1 Gerenciador de Tarefas do Windows XP Processamento de um filme, udio em um ncleo,
vdeo em outro.

2.2 Aumento de desempenho em uma tarefa importante

Outras aplicaes podem utilizar dois ncleos para diminuir o tempo de execuo de
certa tarefa considerada importante e que merea ser realizada em menor tempo. Um
bom exemplo a compactao de um arquivo, pode-se obter em um cenrio ideal, uma
diminuio de 50% no tempo necessrio para a compactao de um arquivo. A
utilizao dos dois ncleos ser mxima e possvel que as tarefas menos importantes
do sistema operacional e os outros programas que estavam em execuo sofram uma
queda de desempenho. [Citao] - FIGURA
Alm disso, quando temos um processador de ncleo nico, as diversas tarefas que
esto sendo executadas muitas vezes sem a interveno do usurio, como carregamento
e interpretao de drivers do sistema operacional, servios de aplicativos e requisies
de conexo de sites da internet podem consumir um tempo de processador precioso,
impedindo um bom desempenho da tarefa principal para o usurio. Se utilizarmos um
processador de ncleo duplo e se o sistema operacional, seus drivers e servios de
aplicativos forem programados utilizando o paradigma concorrente, pode-se utilizar
apenas um dos ncleos para essas tarefas, enquanto o outro continua livre para processar
a aplicao principal com um desempenho superior.

3
Figura 2 Gerenciador de tarefas Windows XP Uso total de todos os ncleos para o processamento de
uma imagem tridimensional no menor tempo possvel.

4
Figura 3 Software alternando a porcentagem de uso dos ncleos conforme os threads
vo sendo iniciados ou finalizados.

3. Desvantagens da programao concorrente

3.1 Dificuldade de programao tratamento de threads

Ao utilizar o paradigma concorrente, o programador poder utilizar vrios recursos, o

mais conhecido so os threads (processos leves), que dividem o trabalho que necessita
ser realizado em duas ou mais partes. Dessa forma o processador no necessita aguardar
o trmino de uma instruo para iniciar outra como ocorre no paradigma estruturado
clssico, pode-se iniciar no mnimo duas tarefas simultaneamente quando utilizamos um
processador de ncleo duplo.
Mas para a utilizao desses threads estritamente necessrio um controle rigoroso dos
componentes utilizados por ela, pois como estaro sendo executados dois ou mais
processos que pertencem a uma mesma aplicao, corremos o risco de um comando de
um thread requisitar acesso a uma regio da memria que j est utilizada por outra.
Isso causaria no pior caso uma interrupo repentina na execuo do programa,
podendo levar perda de informaes importantes contidas na memria de execuo
que ainda no haviam sido gravadas em um lugar definitivo.
O grande empecilho na adoo da programao concorrente est no excesso de esforo
necessrio por parte do programador para acompanhar e controlar as modificaes ou
acessos que esses threads fazem ao longo do programa. Um mtodo comum para o
controle dos threads, a Sincronizao Condicional.

5
3.1.1 Sincronizao Condicional

Para que um thread no interfira em outro, usa-se dois tipos de sinal, o WAIT (espere) e
o NOTIFY (sinal para prosseguir). Supondo uma situao onde dois threads possuam
trecho de cdigo que instrui para acessar uma mesma rea de memria, o primeiro
thread teria de emitir o sinal WAIT para a segunda, e assim que realizasse todas as
operaes necessrias com aquela rea da memria, enviaria o NOTIFY para o segundo
thread iniciar seu acesso. Isso seria a situao ideal. Porm no assim que ocorre em
algumas implementaes do UNIX. Dependendo da implementao pode haver uma
perda de sinal entre os threads causando a no-execuo de determinada tarefa por uma
das threads, impactando todo o andamento da aplicao.

Figura 3 Ilustrao dos sinais de controle

3.2 Baixo suporte de hardware

Os fabricantes de processadores para computadores pessoais esto lanando muitos

modelos de ncleo duplo e at qudruplo no mercado atual. Mas isso no significa que
haja uma grande demanda por eles ou que as pessoas estejam trocando todos os seus
computadores por esses.
Muitos desktops e notebooks so ainda vendidos com apenas um ncleo de
processamento, pois os preos dos processadores de ncleo duplo so altos demais. E
ainda no justificam a compra, pois os usurios finais dificilmente utilizam todo o
potencial que eles proporcionam. Para utilizar um editor de texto, uma planilha
eletrnica, escutar msica e navegar na internet, pode-se utilizar um processador de
apenas um ncleo 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 forar o usurio a substituir o seu por um mais atualizado,
no mostraram tanta exigncia, houve um aumento no consumo de memria, mas nada
proporcional ao aumento de utilizao de capacidade de processamento.
Sem hardware para utilizar o potencial dos softwares, fica mais difcil ainda a adoo da
programao concorrente, j que no h uma demanda global. Essa demanda s deve
realmente surgir quando novas tecnologias como o HD-DVD, Blue-Ray, e HDTV forem
amplamente distribudas at mesmo nos pases em desenvolvimento. Esses padres de
multimdia utilizam muitos recursos de processamento, e so uma boa aplicao para o
paradigma.

6
 Figura 4 Gasto com processadores Single Core (Um ncleo) e Multicore (Vrios ncleos) em 2005 e
2006 para uso em servidores

A figura acima apresenta dados interessantes quanto adoo da tecnologia de vrios

ncleos, percebemos que nos anos de 2005 e 2006 houve um rpido crescimento nas
vendas de processadores de vrios ncleos para servidores que utilizam o sistema
operacional Unix, mas um crescimento no consistente nas outras plataformas.
Se esse cenrio se apresenta em um terreno onde os programas desenvolvidos com a
concorrncia como foco, no animador, o que pensar do mercado global para o
usurio final?

4.Concluso

No existe a base de hardware instalada necessria hoje para alavancar o

desenvolvimento em larga escala de sistemas concorrentes. Claro que possvel o
desenvolvimento de software em paradigma concorrente para um processador com
apenas um ncleo, porm no a que o paradigma mais bem utilizado. Alm disso,
necessrio um maior grau de conhecimento e treinamento do desenvolvedor para chegar
a bons resultados sem problemas de controle dos threads. As linguagens de
programao oferecem bibliotecas e compiladores para o desenvolvimento, porm no
h grande interesse na mudana de paradigma, ainda difcil hoje encontrar pessoas que
deixem as facilidades do paradigma estruturado. A programao concorrente exige
tempo, investimento em treinamento, depurao e testes maiores, pois existem mais
situaes a prever e maiores possibilidades de erros ou conflitos nas aplicaes devido
necessidade de sincronia perfeita entre os threads.
Alm disso, no h uma disseminao em larga escala de processadores de vrios
ncleos, a grande maioria dos computadores do mundo utiliza apenas um ncleo de
processamento. Isso tambm desmotiva o desenvolvedor a mudar de paradigma, pois
seu produto no ser utilizado da maneira que foi projetada, ou no ter o mesmo
desempenho.

7
Referncias - URLs

2 Silva, Dilme Menezes (1999) Introduo Programao Concorrente para a Internet

Disponvel em: http://www.inf.puc-rio.br/~francis/intro_prog_concor.pdf

http://bc.tech.coop/blog/060105.html - Bits and pieces (mostly Lisp-related) that I

collect from the ether. Acesso em 18 Jun 2007.

http://www.tbray.org/ongoing/When/200x/2004/12/13/Multicore - Software in the TLP

Era Acesso em 18 Jun 2007.

http://www.dc.ufscar.br/~mdchiodi/ProgramacaoConcorrente/Pc.html - Curso de
Programao Concorrente. Acesso em 18 Jun 2007.

http://www.cacs.louisiana.edu/~mgr/404/burks/pcinfo/progdocs/plbook/concurre.htm -
Concurrent Programming. Acesso em 17 Jun 2007.

http://en.wikipedia.org/wiki/Concurrent_computing#Advantages Wikipedia -
Concurrent computing. Acesso em 17 Jun 2007.

http://www.cdrinfo.com/Sections/Reviews/Print.aspx?ArticleId=19231 - Intel Ignites

Quad-Core Era

http://www.intel.com/products/processor/xeon/idc_quadcore.pdf - Quad-Core
Processors Bring Higher Performance and Lower Cost to Mainstream Computing
Matthew Eastwood Kenneth Cayton, Abril 2007 - Acesso em 18 Jun 2007

ftp://ftp.aw.com/cseng/authors/finkel/apld/finkel07.pdf - Concurrent Programming -

Acesso em 18 Jun 2007

http://www.phptr.com/content/images/0131013769/samplechapter/hughesch01.pdf -
The Joys of Concurrent Programming Acesso em 16 Jun 2007

http://www.cs.utexas.edu/users/psp/SafetyProgress.pdf - A Logic for Concurrent

Programming: Safety Acesso em 16 Jun 2007