PORTIFOLIO Recupera Theards

1 INTRODUO
O poder computacional est a cada dia mais presente no

cotidiano. Percebese isso, com o aumento no nmero de dispositivos
mveis, computadores pessoais, e a computao na nuvem, que em
muitos casos utiliza-se de grandes data centers. Estima-se que
somente os data centers sejam responsveis por Cerca de 1,5% de
eletricidade total consumida no planeta, e este montante deve
crescer a menos que utilize-se mecanismos que reduzam esse
consumo e ainda assim atendam aos requisitos de processamento
(SHARAVANAN; POONGODI;
KUMAR, 2010).
Com
enfoque
no
aquecimento
global,
pesquisadores
de
computao tm
tomado conscincia sobre o consumo energtico em sistemas
computacionais e os impactos causados por esses no meio ambiente,
gerando ento uma rea de pesquisa ainda recente, a Computao
Sustentvel (Green Computing), que tem por objetivo prover um
conjunto de prticas voltadas para a computao de modo que
minimize-se o impacto ambiental (KURP, 2008).
Em sistemas computacionais, a eficincia energtica pode ser
obtida atravs de otimizaes tanto de hardware como software,
desde o projeto do circuito, passando pelo sistema operacional,
compiladores, chegando at o nvel de aplicao. Contudo, tem-se
como limitante da reduo de consumo que os
requisitos temporais dos aplicativos continuem sendo atendidos,
mesmo que
possam ocorrer perdas no desempenho.
Com o advento de arquiteturas multicore, a programao
paralela tem papel fundamental na melhoria da eficincia, por fazer
melhor proveito dos recursos de hardwares disponveis e aumentar o
desempenho das aplicaes (MRet al., 2010). Um modelo de
programao concorrente muito utilizado o
multithreaded (ANDREWS, 2000). Neste modelo, o paralelismo

explicitado por threads, que compartilham a memria por padro. A
comunicao entre threads concorrentes feita atravs da escrita
e/ou leitura em variveis compartilhadas e h necessidade de utilizarse de mecanismos de sincronizao para garantir a integridade e
consistncia de execuo entre threads concorrentes (ANDREWS,
2000).
Os mecanismos de sincronizao tm sido tradicionalmente
realizados atravs de mtodos baseados em locks explcitos no
cdigo fonte dos programas.
Embora muito utilizado, esta abordagem propensa a erros,
podendo
apresentar
uma
srie
de
complicaes
tais
como
(MCKENNEY et al., 2010): instabilidade no sistema, dificuldade de

composio e baixo desempenho se no empregado corretamente.
Novas abstraes que facilitem o desenvolvimento de aplicaes
paralelas so portanto essenciais (BALDASSIN, 2009).
1.1 Objetivos
Este trabalho tem como objetivo principal analisar mecanismos
de sincronizao em ambiente de memria compartilhada sob o
contexto da computao sustentvel, visando a reduo no consumo
de energia e/ou maximizao do desempenho. Especificamente, temse como objetivos: realizar uma reviso bibliogrfica do assunto,
apresentando
as
caractersticas
(vantagens
problemas)
da
programao concorrente, com destaque para o mecanismo de

memrias transacionais; e realizar um estudo investigativo em
pesquisas j concretizadas que comparam o consumo de energia e/ou
o desempenho de memrias transacionais com outros mecanismos de
sincronizao.
1.2 Organizao do texto

O trabalho que segue est organizado em 5 Captulos. O
Captulo 2 apresenta a computao sustentvel, suas origens e
motivaes. O Captulo 3 tem por objetivo descrever os principais
tpicos sobre comunicao e sincronizao
11 em programao
concorrente,
os
mostrando
os
problemas
mecanismos
de
sincronizao que visam garantir a consistncia e integridade em

execues concorrentes. No Captulo 4 ser apresentado uma anlise
das pesquisas j desenvolvidas objetivando reduo no consumo de
energia e/ou desempenho em mecanismos de sincronizao em
ambiente de memria compartilhada. Por fim, no Captulo 5 sero
apresentadas as concluses e os trabalhos futuros.
COMPUTAO SUSTENTVEL
A utilizao de sistemas computacionais faz-se cada vez mais presente
em atividades das mais diferentes naturezas. Diversas reas do conhecimento
utilizam-se de aplicaes que oferecem suporte automatizado para diversas
tarefas, cujo suporte executivo tanto baseia-se em hardware como software.
Nos lares, cresce-se de igual modo a utilizao de dispositivos mveis e
computadores pessoais, que servem, fundamentalmente, como equipamentos
para lazer e comunicao.
2.1 Origens
Nos ltimos anos, a relao entre o consumo energtico em sistemas
computacionais e os impactos ambientais causados por esses cunharam o
termo
computao sustentvel.
Embora a computao sustentvel tenha recentemente se popularizado,
suas origens conceituais vm h mais de duas dcadas (HARMON;
AUSEKLIS,
2009). Em 1991, a Environmental Protection Agency (Agncia de Proteo
Ambiental) introduziu o programa Green Lights para promover a eficincia
energtica em iluminao. Em seguida, introduziu-se o programa Energy
Star em 1992, o qual estabeleceu especificaes de eficiente energtica para
computadores e monitores (HARMON; AUSEKLIS, 2009).
A popularizao da computao sustentvel deveu-se principalmente ao
rpido crescimento de negcios baseados na internet, e os custos de energia
para suprir as demandas de infra-estruturas da tecnologia da informao
(HARMON;AUSEKLIS, 2009). Apesar de o consumo energtico e seus custos
associados terem sido o fator impulsor para o surgimento da computao
sustentvel, foi a partir das alteraes climticas oriundas do aquecimento
global
que os benefcios gerados pelas prticas da computao sustentvel ganharam
notoriedade a nvel mundial (HARMON; AUSEKLIS, 2009).
2.2 Objetivos e prticas

A Computao Sustentvel consiste em um somatrio de prticas,
tais que o
principal objetivo obter uma minimizao dos impactos causados
por sistemas
computacionais no meio ambiente.
O meio ambiente beneficia-se da computao sustentvel por meio
do
consumo eficiente de energia, na reduo de emisses de gases de
efeito estufa,
menor uso de materiais nocivos na fabricao de computadores, e

atravs do
incentivo na reutilizao e reciclagem de componentes de hardwares
(MURUGESAN,2008). Tais prticas fomentam melhorias nas atividades
de empresas e clientes, efetivando redues em custos e contribuem
com maior preservao do meio ambiente.
Em relao aos data centers, pode-se melhorar a eficincia desses
utilizandose
de equipamentos eficientes em termos energticos, reduzindo-se a
necessidade
de refrigerao, utilizando-se de softwares de gerenciamento de
14 energia (MURUGESAN, 2008).
Outra prtica que pode colaborar significativamente na reduo de
custos e
energia a Virtualizao, pois permite particionar um nico sistema
computacional
em vrios outros denominados de mquinas virtuais, reduzindo-se
assim
a quantidade de mquinas, espao fsico, refrigerao, entre outros
elementos
necessrios para o funcionamento do ambiente computacional
(MURUGESAN,
2008).
O aumento da eficincia energtica importante em todo contexto
computacional,
independente de hardwares e softwares utilizados. Com o advento
de arquiteturas
multicore, a programao paralela tem papel
fundamental na
melhoria da eficincia, por fazer melhor proveito dos recursos de
hardwares
disponveis e aumentar o desempenho das aplicaes (MR et al.,
2010).
Uma das caractersticas de processadores multicore est relacionada

a
maior
capacidade
de
processamento
utilizando-se
de
menor
frequncia de
operao. Em tais processadores, para cada 1% de ganho de
desempenho
h 3% de consumo de energia (RAMANATHAN; THOMAS, 2005).
Utilizandose
desta relao de maneira inversa, de se esperar que diminuindo
15% da
frequncia de operao de um determinando processador, 45% de
energia ser
economizada. O consumo de energia de processadores pode ser
obtido atravs
da equao 1 (WECHSLER, 2006). C representa a capacitncia
comutada,
ou seja, a quantidade de energia que pode ser armazenada em um
capacitor
equivalente. V a tenso de alimentao, f a frequncia do clock. A
capacitncia comutada tem um valor fixo para cada circuito, mas a
tenso de
alimentao e a frequncia do clock podem ser reduzidos em certos
limites.
Observa-se na equao 1 a dependncia da tenso (em Volts) em
relao
frequncia de clock.
Power = C _ V 2 _ f (1)
Atravs da tcnica conhecida como DVFS (Dynamic Voltage and
Frequency
Scaling) (KAXIRAS; MARTONOSI, 2008), a voltagem e frequncia de
operao
dos ncleos de execuo de processadores podem ser reduzidas em
tempo
de execuo, de acordo com a demanda computacional, obtendo-se

assim, a
reduo do consumo de energia em ordem quadrtica. No entanto, a
realizao
destas
operaes
apresenta
um
custo
associado,
podendo
comprometer o
desempenho global do sistema. Para a realizao de tal tcnica,
primeiramente,
a voltagem do processador/core deve ser alterada, para que essa
possa suportar
a frequncia exigida, somente aps esta etapa a frequncia pode ser
alterada
para
desejada.
Durante
realizao
destas
operaes,
processador deve
interromper suas atividades e aguardar a finalizao do ajuste,
acarretando em
tempo de processamento perdido (UHRIG; UNGERER, 2005). Portanto,
deve-se
levar em considerao que tais operaes no sejam frequentes e
assim tomar
tempo de processamento, e que o ajuste seja realizado de tal forma
afim de
garantir os requisitos temporais do sistema.
Em arquiteturas multicore e multiprocessadas, um recurso de
programao
conhecido como Afinidade permite associar threads a um, ou a um
grupo, de
processadores/cores (ARAUJO et al., 2010). O objetivo deste recurso
explorar
a localidade de referncia a dados na memria cache. Este recurso
permite
15
utilizar a memria cache de maneira mais eficiente, pois ocorrem

menos cache
miss, pois um thread em especfico ser sempre executada sobre o
mesmo
processador/core ou grupo de processadores/cores. A explorao do
recurso de
Afinidade pode ser utilizada em conjunto com a tcnica de DVFS,
como mostrado
por Araujo et al (2010). Nesta perspectiva, observou-se que a
utilizao de tais
tcnicas em conjunto eficiente, tanto em termos de consumo de
energia quanto
desempenho.
A organizao e arquiteturas de processadores paralelos podem
colaborar
ainda mais na reduo do consumo energtico. Seja atravs de
componentes
de hardwares que visam menor consumo de energia (low-power ), ou
at mesmo,
atravs do desligamento seletivo de unidades de processamento que
no
estejam sendo utilizadas em uma certa poro de tempo, reduzindose assim, o
consumo de potncia (MR et al., 2010). No contexto de arquiteturas
multicore e
multiprocessadas, a utilizao da programao paralela um fator
determinante
para a busca da eficincia energtica, pois utiliza-se dos recursos
disposio
de
maneira
eficiente,
utilizando
ao
mximo
uso
de
processadores/cores que j
esto ativos, diminuindo sua ociosidade. Assim, aproveita-se a
energia que estes
esto
consumindo,
evitando-se
desta
forma
uso
de
processadores/cores
extras (MR et al., 2010).
2.3 Observaes finais

Este
Captulo
apresentou
os
conceitos
relacionados
computao sustentvel,
os problemas e resolues devido a expanso da computao.
Diversas prticas provenientes da programao paralela foram
mostradas
com objetivo de relacionar esta abordagem de programao
computao
sustentvel. Especificamente, mostrou-se que a programao
paralela pode
reduzir o consumo de energia de sistemas computacionais,
atravs de tcnicas
que
utilizam
eficientemente
os
recursos
de
hardwares
disponveis.
Com a crescente demanda por recursos computacionais, elevase tambm
o consumo de recursos ambientais. Com isso, a computao
sustentvel tem
o propsito de otimizar a computao de modo a utilizar o
mnimo necessrio
de recursos naturais, garantindo ainda, que as demandas de
processamento e
requisitos temporais dos aplicativos sejam atendidas.
3 COMUNICAO E SINCRONIZAO
A execuo concorrente em sistemas se torna interessante
pelos seguintes
aspectos (SILBERSCHATZ; GALVIN; GAGNE, 2009):
_ Compartilhamento de informaes: Em sistemas multiusurio,
diversos
usurios podem estar interessados na mesma informao, por

exemplo, um
arquivo compartilhado. O sistema deve ser capaz de fornecer
um ambiente
que permita o acesso concorrente aos recursos compartilhados.
_ Processamento mais veloz: Para executar uma tarefa mais
rapidamente,
deve-se subdividi-la em sub-tarefas, onde cada sub-tarefa ser
responsvel
pela execuo de uma parte dos dados ou de uma operao
especfica. O
aumento na velocidade s obtido na sub-diviso de tarefas
em ambientes
com mltiplos elementos de processamento.
_ Modularidade: A construo de sistemas de forma modular,
dividindose
as funes em processos ou threads separados, em um sistema
multiprocessado se torna vantajoso, pois cada funo pode ser
executada
por um determinado elemento de processamento.
_ Comodidade: A execuo de diversas tarefas simultneas se
tornou uma
prtica usual. Por exemplo, um usurio pode estar editando um
texto,
ouvindo msica, e gravando arquivos em algum tipo de mdia
ao mesmo
tempo.
Para que haja cooperao entre execues concorrentes em
sistemas,
h necessidade dessas se comunicarem. Existem dois modelos
comuns de
comunicao entre processos ou threads: memria compartilhada
e troca
de mensagens (SILBERSCHATZ; GALVIN; GAGNE, 2009). No modelo

de
memria compartilhada, processos utilizam-se de chamadas de
sistema do
tipo mapeamento da memria para obter acesso a regies da
memria utilizadas
por outras tarefas. Threads por sua vez, compartilham a
memria por padro.
A troca de informaes entre processos/threads ocorre por meio
de leituras
e gravaes das reas da memria compartilhada. No modelo de
troca
de mensagens, a comunicao entre processos realizada
atravs da troca
de informaes por intermdio de um canal de comunicao. O
meio de
comunicao pode ser implementado de vrias formas, como
por exemplo
um buffer ou link de uma rede de conexo. Esta abordagem
apropriada
para sistemas distribudos, pois tais sistemas so compostos de
vrias CPUs
17
contendo reas de memrias privativas, sendo essas CPUs
conectadas atravs
de uma rede de interconexo (SILBERSCHATZ; GALVIN; GAGNE,
2009).
Este trabalho tem como objetivo realizar um estudo sobre
mecanismos de
sincronizao
em
ambientes
de
memria
compartilhada
baseado no modelo
multithreaded, portanto no sero discutidos maiores detalhes
sobre troca de
mensagens no decorrer do mesmo.

Nas duas prximas sees, sero respectivamente descritos o
que denominase
de seo crtica de um programa e os problemas que podem
ocorrer durante
a comunicao entre processos/threads concorrentes. Na Seo
3.3 sero
descritos os mecanismos de sincronizao. E por fim, na Seo
3.4 sero
apresentadas as observaes finais.
3.1 Seo Crtica

Denomina-se Seo Crtica a parte de cdigo de um programa
em que a
memria ou recurso compartilhado acessado, ou seja, os
trechos de cdigo
que
manipulam
os
dados
compartilhados
onde
possam
ocasionar condies de
corrida (TANENBAUM; WOODHULL, 2008).
Mostra-se na Figura 1 um cdigo escrito na linguagem Java que
representa
a estrutura de um programa que manipula valores de uma
conta bancria. As
sees crticas do cdigo mostrado so aquelas em que o
atributo saldo
manipulado (linhas 8 e 16), pois o atributo compartilhado na
estrutura do
programa,
na
qual
diversas
threads
concorrentemente e utilizar
o recurso compartilhado da classe Java.
1
2
public class ContaBancaria {
3
4
pr ivate double saldo = 0;
5
6
public void deposi ta ( double quant ia ) {
podem
executar
i f ( quant ia > 0) {
this . saldo = this . saldo + quant ia ; / / Seo Cr t i c a
} else {
10
System. out . p r i n t l n ("A quantia do depsito deve ser maior
que ZERO.") ;
11
12
13
14
public void saque ( double quant ia ) {
15
i f ( this . saldo quant ia > 0) {
16
this . saldo = this . saldo quant ia ; / / Seo Cr t i c a
17
} else {
18
System. out . p r i n t l n ("Saldo insuficiente para o valor de
saque desejado.") ;
19
20
21
Figura 1: Estrutura de um programa com Seo Crtica

O problema da seo crtica est em garantir que somente uma
tarefa possa
18
estar executando sua seo crtica no mesmo intervalo de
tempo. A garantia
que duas ou mais tarefas no acessem simultaneamente a
mesma seo crtica
denomina-se de excluso mtua.
Diversas primitivas que solucionam o problema da seo crtica
estabelecem
um protocolo onde define-se uma condio para a tarefa entrar
na seo crtica
e outra operao que sinalize que a tarefa concluiu a execuo
da seo
crtica (SILBERSCHATZ; GALVIN; GAGNE, 2009).
Para que tarefas concorrentes mesma seo crtica sejam
executadas de
forma
eficiente
correta,
devem
ser
satisfeitas
quatro
condies (TANENBAUM;
WOODHULL, 2008):
_ Excluso mtua: Duas ou mais tarefas no podem estar ao
mesmo tempo
dentro da mesma seo crtica.
_ Independncia de fatores fsicos: A soluo no deve depender da
velocidade
de
execuo
das
tarefas
ou
do
nmero
de
processadores
disponveis.
_ Progresso: Nenhuma tarefa executando fora de sua seo
crtica pode
bloquear outras tarefas.
_ Espera limitada: Nenhuma tarefa pode ter seu ingresso na seo
crtica
postergado indefinidamente.
3.2 Problemas de concorrncia

Diversos problemas podem ocorrer durante a comunicao
entre processos/
threads concorrentes, tem-se como soluo para tais, a
utilizao de
mecanismos de sincronizao, que sero descritos na subseo
3.3. A seguir,
sero
apresentados
os
problemas
mais
conhecidos
em
ambiente de memria
compartilhada.
3.2.1 Condio de corrida
Se duas ou mais tarefas (threads ou processos) tentam alocar o
mesmo
recurso
ou
dado
compartilhado
ao
mesmo
inconsistncias de dados
podem ocorrer (TANENBAUM; WOODHULL, 2008).
tempo,
Denomina-se
de
condies
de
corrida
as
inconsistncias
geradas por acessos

simultneos a dados ou recursos compartilhados (TANENBAUM;
WOODHULL,
2008).
Podem ocorrer condies de corrida em qualquer sistema onde
haver acesso
concorrente a um mesmo recurso compartilhado, mas ao menos
uma das
operaes seja de escrita no recurso. Acessos de leitura
concorrente a um
recurso compartilhado no geram condies de corrida, pois
no alteram o valor
do recurso compartilhado.
Para resguardar-se da condio de corrida precisa-se garantir
que somente
um processo/thread manipular o recurso compartilhado por
vez, utilizando-se
de mecanismos de sincronizao (SILBERSCHATZ; GALVIN;
GAGNE, 2009).
Demonstra-se atravs da Figura 2 a ocorrncia de condio de
corrida em
uma aplicao, atravs de um digrama temporal de execuo
de um programa
19
que manipula valores de uma conta bancria, baseado na
estrutura de cdigo
mostrado na Figura 1.
Figura 2: Acesso concorrente entre threads - demonstrao de
condio de
corrida
Observa-se na Figura 2 que a condio de corrida ocorreu pois
no mesmo
instante de tempo as duas threads alocam o mesmo recurso na

memria
(varivel saldo), assim, o valor da varivel alocada ser
inconsistente, pois uma
das atualizaes de ambas threads ser perdido, desta forma o
resultado final
ser no-determinstico.
3.2.2 Deadlock e Livelock
Por definio, um conjunto de processos/threads est em
deadlock (impasse)
se cada processo/thread do conjunto est esperando por um
evento que apenas
outro processo/thread do conjunto pode causar (TANENBAUM;
WOODHULL,
2008).
Dessa forma, deadlocks causam bloqueios perptuos em
processos/threads,
pois espera-se por um evento (liberao do recurso) que nunca
ir acontecer.
Para que ocorram deadlocks, quatro condies devem ser
verdadeiras (COFFMAN;
ELPHICK; SHOSHANI, 1971):
1.
Condio
de
excluso
mtua:
Cada
recurso
ou
est
correntemente
atribudo a exatamente um processo/thread ou est disponvel.
2. Condio de posse e espera: Os processos/threads que
correntemente
possuem recursos garantidos anteriormente podem solicitar
novos recursos.
3. Ausncia de preempo: Os recursos garantidos anteriormente
no
podem ser retirados fora de um processo/thread. Eles devem
ser
liberados explicitamente pelo processo/thread que os possui.

20
4. Condio de espera circular: Deve haver um encadeamento
circular de
dois ou mais processos/threads, cada um dos quais esperando
por um
recurso mantido pelo prximo membro do encadeamento.
As
quatro
condies
descritas
anteriormente
podem
ser
modeladas usando
grafos dirigidos (HOLT, 1972). Dois tipos de ns so utilizados
nos grafos:
processos, mostrados como crculos, e recursos, mostrados
como quadrados.
Um arco de um n de processo (crculo) para um n de recurso
(quadrado)
significa que o processo est bloqueado, esperando por esse
recurso. Um arco
de um n de recurso para um n de processo significa que o
recurso foi solicitado
anteriormente, foi concedido e correntemente mantido por
esse processo.
A Figura 3(a) mostra graficamente uma situao de deadlock. O
processo
P4 est bloqueado espera do recurso R2, mantido pelo
processo P1. Os
processos P1 e P3 esto bloqueados espera do recurso R1,
mantido pelo
processo P4. Desta forma, P1, P3 e P4 esto em deadlock. Na
Figura 3(b), o
processo P5 est bloqueado espera do recurso R3. Entretanto,
o processo P5
no est em deadlock, pois o processo P2 no est bloqueado,
podendo esse
executar at o fim, liberar o recurso R3, e ento o processo P5

poder executar.
Figura 3: Cenrios de alocaes de recursos compartilhados
com ocorrncia de
deadlock. Fonte: (OLIVEIRA; CARISSIMI; TOSCANI, 2008)
H vrias formas de eliminao de deadlocks em sistemas. Uma
delas
se, para cada recurso, for eliminada pelo menos uma das quatro
condies
descritas acima (TANENBAUM; WOODHULL, 2008). Uma outra
forma usual
para o tratamento de deadlocks deixar acontecer, detect-lo e
ento eliminlo
(TANENBAUM;
WOODHULL,
2008).
deteco
pode
ser
realizada de forma
automtica ou manual. O deadlock eliminado por meio da
destruio dos
processos/threads envolvidos e da liberao dos respectivos
recursos.
Livelock semelhante deadlock, com a diferena que os
estados dos
processos/threads em livelock no ficam bloqueados, mas
permanecem em
estado de espera-ocupada (ANDREWS, 2000).
Um exemplo de uma situao que ocorre livelock quando duas
pessoas
caminhando em um corredor estreito em direes opostas se
encontram frente a
frente. Ambas tentam seguir caminho em frente, porm, cada
uma se move para
o mesmo lado, no conseguindo progresso, pois moveram-se
para o mesmo
lado ao mesmo tempo.
Situaes como a do exemplo descrito anteriormente so

comuns de acontecer
em certos ambientes, porm, eventualmente, o progresso
acontece (ANDREWS,
2000).
21
3.2.3 Starvation
Starvation, ou inanio, refere-se ao tempo indefinido que
processos/threads
aptos a execuo aguardam para executar. Tal situao pode
ocorrer em
algoritmos
de
escalonamento
por
prioridades,
pois
processos/threads de prioridade
mais alta pode levar a que processos/threads de baixa
prioridade
ficarem esperando indefinidamente para serem escalonados e
executados pela
CPU (SILBERSCHATZ; GALVIN; GAGNE, 2009). Outra situao em
que a
inanio pode ocorrer em sincronizao por espera-ocupada,
na qual algum
processo/thread em especfico pode sempre perder na disputa
pela entrada na
seo crtica (OLIVEIRA; CARISSIMI; TOSCANI, 2008).
Uma soluo que resolve o problema da inanio em algoritmos
de escalonamento
por prioridades a tcnica conhecida como envelhecimento, na
qual
incrementa-se gradualmente a prioridade dos processos/threads
que aguardam
em filas por longo tempo para executarem (SILBERSCHATZ;
GALVIN; GAGNE,
2009).
3.2.4 Inverso de prioridade

Denomina-se de inverso de prioridade situaes em que
processos/threads
de alta prioridade so impedidos de executar suas sees
crticas por essas j
estarem sendo executadas por processos/threads de mais baixa
prioridade (SILBERSCHATZ;
GALVIN; GAGNE, 2009). Somente aps o processo/thread de
baixa prioridade concluir a execuo da seo crtica a tarefa de
alta prioridade
poder prosseguir.
3.3 Primitivas de sincronizao

O objetivo de mecanismos de sincronizao garantir a
integridade e
consistncia em execues concorrentes, controlando a ordem
de execuo das
operaes
entre
diferentes
tarefas.
Duas
formas
de
sincronizao se fazem
necessrias em aplicaes concorrentes: condicional e excluso
mtua (ANDREWS,
2000). A sincronizao condicional permite postergar a execuo
de um processo ou thread at que alguma condio se
satisfaa. A excluso
mtua garante que no haver acesso simultneo em uma
regio de memria
compartilhada.
Mecanismos
de
sincronizao
tm
sido
tradicionalmente
implementados com
uso de bloqueios (locks) explcitos pelo programador, onde
certas variveis
representam a proteo (entrada e sada) da seo crtica, ou a
condio
para postergao ou avano de determinadas tarefas. As

implementaes
de locks podem ser classificadas conforme sua caracterstica.
Existem basicamente
duas
classificaes:
bloqueantes
espera-ocupada
(TANENBAUM;
WOODHULL, 2008). A caracterstica bloqueante refere-se
retirar do escalonamento
(suspender) os processos/threads quando esses no podem
entrar em
suas sees crticas at que alguma condio se satisfaa. Na
espera-ocupada
o processo/thread verifica se a entrada permitida na seo
crtica, se no for,
o processo/thread executar um lao fechado at que seja
permitido entrar.
No entanto, apesar de ser muito utilizado, este modelo de
programao
apresenta uma srie de problemas (JONES, 2007) (MCKENNEY et
al., 2010):
22
_ Instabilidade: como o controle sobre a forma de sincronizao
dada
atravs de locks explicitados pelo programador, torna-se
comum algumas
situaes acontecerem: a utilizao de locks em excesso;
adquirir menos
locks do que o necessrio; adquirir locks errados; adquirir locks
na ordem
errada. Tais situaes podem acarretar em: diminuio do
paralelismo,
condies de corrida e deadlocks. Por essas razes, como
consequncia,
tem-se uma complicao na criao de sistemas confiveis e

escalveis
baseados em locks.
_ Composio: no h garantia em que trechos de cdigo
corretamente
implementados
utilizando
bloqueios,
quando
combinados,
continuem vlidos.
Por exemplo, uma operao que deva mover um item entre
duas
filas poderia ser composta atravs de mtodos de remoo e
insero,
sendo requerido atomicidade na execuo (ou seja, no pode
ser percebida
a ausncia do item em uma fila antes que o mesmo seja
inserido em
outra). No entanto, atravs do uso de bloqueios torna-se
complicado tal
composio sem que o encapsulamento do objeto seja violado
ou ainda
que novos bloqueios sejam introduzidos.
_
Gargalo
serial:
fator
desempenho
est
relacionado
diretamente
caracterstica conservativa dos bloqueios. Em sees crticas
protegidas
por
bloqueios
acesso
restringido,
apenas
um
processo/thread pode
acessar por vez. Quando um processo/thread tentar acessar
uma regio
de cdigo protegida que j est sendo acessada, esse
processo/thread
ficar bloqueado at o recurso ser liberado, causando gargalos
seriais no
sistema. Quanto maior a granularidade do cdigo protegido por

um bloqueio,
maior
ser
impacto
negativo
no
desempenho
na
escalabilidade
da aplicao. A anlise de tal impacto pode ser obtida
utilizando-se da lei
de Amdahl (AMDAHL, 1967), a qual relaciona o acrscimo de
desempenho
esperado em um algoritmo que possui parcelas sequenciais e
paralelas,
dada pela equao 2. A equao descreve o speedup mximo
S(p) obtido
com p processadores em um programa cuja frao de tempo de
execuo
serial dada por fs.
S(p) =
1
fs +
1fs
(2)
Mesmo para um nmero de processadores que tende ao infinto,
o speedup
limitado pela frao de cdigo serial presente em um
programa.
Desta forma, em uma aplicao cuja 50% do tempo de
execuo seja
estritamente sequencial, o speedup mximo obtido ser 2,
independente
do nmero de processadores utilizados, de acordo com a
equao 3.
lim
p!1
S(p) =
1
fs
(3)
Com base nas equaes descritas anteriormente, evidencia-se
que a
granularidade da sincronizao e a frao serial do cdigo de
um programa
23
so fatores determinantes no desenvolvimento de algoritmos
concorrentes
eficientes.
Embora apresente uma srie de desvantagens, o mecanismo de
locks tem
como vantagens possibilitar uma programao intuitiva e fcil
de usar em muitos
casos,
diversas
plataforma
de
hardwares
existentes
oferecerem suporte ao
mecanismo, o que evidencia o grande nmero de softwares que
fazem uso deste
modelo, alm de existir um grande grupo de desenvolvedores
experientes que
utilizam o mecanismo (MCKENNEY et al., 2010).
Uma alternativa sincronizao baseada em
locks a
sincronizao nobloqueante,
que tem por objetivo resolver os problemas intrnsecos dos
locks
no acesso recursos compartilhados (ANDREWS, 2000). A
implementao nobloqueante
exclui qualquer uso de locks, j que esses podem induzir estado
de
espera (BALDASSIN, 2009).
So classificados em trs nveis os algoritmos no-bloqueantes,
de acordo
com a garantia de progresso de suas operaes (BALDASSIN,

2009):
1. Livre de espera (wait-free): Todas as operaes terminam aps
um
nmero finito de passos. O sistema como um todo faz
progresso.
2. Livre de trava (lock-free): Alguma operao termina aps um
nmero
finito de passos. H pelo menos uma thread fazendo progresso.
3. Livre de obstruo (obstruction-free): Alguma operao sempre
termina
em um nmero finito de passos quando livre da interferncia de
outras
operaes. Uma thread, quando executada de forma isolada,
sempre faz
progresso.
Dessa forma, a sincronizao livre de espera garante progresso
incondicional
(BALDASSIN, 2009). J a livre de trava admite que determinada
thread
no
faa
progresso,
cenrio
denominado
starvation
(BALDASSIN, 2009). Por

fim, como forma mais fraca, a livre de obstruo no garante
progresso em
condies em que haja threads concorrentes e conflitantes.
Nesse esquema
possvel que threads invalidem uma o trabalho da outra sem
haver progresso
algum, situao conhecida como livelock (BALDASSIN, 2009).
O grande problema com a sincronizao no-bloqueante a
extrema dificuldade
em projetar, implementar e verificar a corretude dos algoritmos
(BALDASSIN,
2009).
Alguns casos reais ressaltam a dificuldade de desenvolvimento
de sistemas
concorrentes. Entre 1985 e 1987, uma condio de corrida
existente no
software para o equipamento de radiao mdico Therac-25
causou pelo menos
seis mortes (LEVESON; TURNER, 1993). Em 1997, falhas
sucessivas de
operao do dispositivo da misso Pathfinder em Marte foram
atribudas a um
problema de inverso de prioridade no software (WILNER,
1997). Problemas
decorrentes de condio de corrida contriburam para um dos
maiores blecautes
da histria norte-americana em agosto de 2003, afetando cerca
de 50 milhes
de pessoas (POULSEN, 2004).
Nas prximas 3 subsees sero descritos diferentes mtodos
de sincronizao,
baseados em locks. Na subseo 3.3.3, ser apresentado o
mecanismo de
Memrias Transacionais, na qual a caracterstica bloqueante ou
no-bloqueante
depende de sua implementao.
24
3.3.1 Semforos
Semforo um mecanismo de sincronizao criado pelo
matemtico holands
E. W. Dijkstra em 1965 (TANENBAUM; WOODHULL, 2008). Um
semforo S uma varivel inteira que, parte a inicializao,
acessada
somente atravs de duas operaes atmicas padres: wait e

signal. Estas
operaes eram originalmente designadas como P (da palavra
holandesa
proberen, que significa testar) e V (da palavra holandesa
verhogen, significando
incrementar) (SILBERSCHATZ; GALVIN; GAGNE, 2009).
As modificaes do valor inteiro do semforo sobre tais
operaes e o
conjunto
de
instrues
no
escopo
dessas,
devem
ser
executadas de modo
indivisvel,
afim
de
evitar-se
condies
de
corrida
(SILBERSCHATZ; GALVIN;
GAGNE, 2009).
Nas Figuras 4 e 5 mostram-se respectivamente as definies
clssicas das
operaes wait e signal.
wai t (S) {
whi le (S <= 0)
; / / nenhuma operao
S;
}
Figura 4: Implementao semforo espera ocupada - instruo

wait.
Fonte: (SILBERSCHATZ; GALVIN; GAGNE, 2009)
s i g n a l (S) {
S++;
}
Figura 5: Implementao semforo espera ocupada - instruo

signal.
Fonte: (SILBERSCHATZ; GALVIN; GAGNE, 2009)
Conforme
mostrado
na
Figura
4,
percebe-se
que
implementao clssica
da instruo wait requer espera em ao (SILBERSCHATZ;
GALVIN; GAGNE,
2009). Este tipo de implementao de semforo tambm

chamado de Spinlock,
e tem como caracterstica, para qualquer processo/thread que
necessitar
acessar a seo crtica, e est j estiver sendo executada por
outro fluxo
de execuo, o processo/thread ir testar repetidamente a
varivel (valor do
semforo) que controla a entrada na seo crtica at essa
indicar que a seo
est liberada.
O teste de uma varivel continuamente at que uma condio
se satisfaa
denomina-se busy-waiting, ou espera ocupada. Isso torna-se uma
desvantagem
do mecanismo Spinlock, pois o processador estar executando o
teste
continuamente na varivel que representa o lock, enquanto
aguarda a seo
crtica tornar-se liberada (TANENBAUM; WOODHULL, 2008). Em
situaes
onde diversas tarefas aguardam simultaneamente e testam
continuamente o
valor de lock at este indicar a liberao da seo crtica,
poder acontecer de
25
algum processo/thread nunca conseguir entrar em sua seo
crtica, pois no h
estabelecido critrios para ordem de execuo da seo crtica,
e sim, depende
de qual fluxo de execuo consegue adquirir o lock primeiro.
Spinlock muito utilizado em situaes nas quais a seo
crtica contm poucas
instrues, sendo assim, a probabilidade de um processo/thread

encontrar a
seo crtica bloqueada muito baixa, reduzindo-se ento o
desperdcio de CPU
e a postergao indefinida.
Para superar a necessidade da espera em ao, pode-se
modificar a
definio das operaes de semforo wait e signal. Em vez do
processo/thread
esperar em ao, o processo/thread deve ser bloqueado. Nesta
implementao,
denominada de bloqueante, o processo/thread antes de acessar a
seo crtica verifica se permitido entrar, se no for, o
processo/thread ser
bloqueado. A operao de bloqueio coloca o processo/thread
em uma fila
de espera associada ao semforo e o estado do processo/thread
comutado
para estado em espera (SILBERSCHATZ; GALVIN; GAGNE, 2009).
Aps um
processo/thread concluir a execuo de sua seo crtica,
verificado se existem
processos/threads
na
fila
de
espera,
se
existirem,
um
processo/thread da fila
associada ao semforo ser retirado para entrar em execuo.
Ambas implementaes de semforo (Spinlock e bloqueante)
resolvem
o problema da seo crtica atravs da implementao da
excluso mtua,
conforme ilustrado pela Figura 6.
wai t (mutex ) ;
Seo c r t i c a ;
s i g n a l (mutex ) ;
Seo remanescente ;
Figura 6: Implementao da excluso mtua com semforos.

Fonte: (SILBERSCHATZ;
GALVIN; GAGNE, 2009)
No
entanto,
implementao
de
semforos
bloqueante
tambm pode ser

usada
para
estabelecer
relaes
de
precedncias
entre
processos/threads (SILBERSCHATZ;
GALVIN; GAGNE, 2009). Por exemplo, um cenrio onde dois
processos operam concorrentemente: P1 com um comando S1 e
P2 com um
comando S2. Suponha-se que o comando S2 deva ser
executado somente
depois que S1 concluir sua execuo. Pode-se implementar este
esquema
deixando que P1 e P2 compartilhem um semforo comum
synch, inicializado
em 0, conforme ilustrado pela Figura 7. Como synch
inicializado em 0, P2
executar somente aps P1 ter invocado signal(synch) o que
feito aps o
comando S1.
A
implementao
bloqueante
pode
variar
conforme
implementao das
operaes wait e signal do semforo. Duas classificaes so
comumente
empregadas, conhecidas como semforo binrio/mutex, e semforo
de contagem.
No mutex, o valor do semforo pode assumir apenas dois
valores, 0 e 1 (livre
e ocupado). As operaes wait e signal so normalmente
chamadas de lock e
26
Processo P1 :
S1 ;
s i g n a l ( synch ) ;
Processo P2 :
wai t ( synch ) ;
S2 ;
Figura 7: Semforos - precedncias entre tarefas. Fonte:

(SILBERSCHATZ;
unlock. Quando um processo ou thread precisar acessar uma
seo crtica ele
dever chamar o comando lock do mutex. A instruo lock
verifica se o mutex
est livre, se estiver, o fluxo em execuo pode entrar na seo
crtica. Em casos
de o mutex estar ocupado o processo/thread inserido na fila,
conforme ilustrado
pela Figura 8.
Lock (mutex ) :
Se mutex est l i v r e Ento
marca mutex como ocupado
Seno
Insere processo / thread no f im da f i l a do mutex
Figura 8: Mutex - operao lock. Fonte: (OLIVEIRA; CARISSIMI;

TOSCANI,
2008)
A instruo unlock verifica se o mutex contm registros na fila
de processos/
threads, se a fila estiver vazia, deve-se marcar a varivel mutex
como livre.
Se a fila no estiver vazia, deve-se liberar um processo/thread
da fila para
execuo da seo crtica, conforme ilustrado na Figura 9.
Unlock (mutex ) :
Se f i l a mutex est vazia Ento
marca mutex como l i v r e
Seno
Libera processo / thread do i n c i o da f i l a do mutex
Figura 9: Mutex - operao unlock. Fonte: (OLIVEIRA; CARISSIMI;

TOSCANI,
2008)
Aps a sada da seo crtica de um processo/thread, este
dever chamar a
instruo unlock do mutex, conforme ilustrado pela Figura 10.
No semforo de contagem, aceita-se valores negativos para o
valor do semforo.
Deste modo, se o valor for negativo, sua magnitude ser igual
ao nmero
de processos/threads em espera na fila daquele semforo
(SILBERSCHATZ;
GALVIN; GAGNE, 2009).
27
Mutex mu = L i v r e ;
...
Lock (mu) ; / _ Entrada da seo c r t i c a _ /
Seo c r t i c a ;
Unlock (mu) ; / _ Sada da seo c r t i c a _ /
Figura 10: Excluso mtua com mutex. Fonte: (OLIVEIRA;

CARISSIMI;
TOSCANI, 2008)
Ao ser executada a instruo wait sobre um semforo de
contagem, o valor
deste dever ser decrementado. Caso o novo valor do semforo
seja negativo, o
processo/thread ser bloqueado e inserido na fila desse
semforo.
wai t (S) :
S. v a l o r = S. va l o r 1;
Se S. va l o r < 0 Ento
Bloqueia processo / thread e insere em S. f i l a ;
Figura 11: Implementao semforo bloqueante - instruo

wait. Fonte: (SILBERSCHATZ;
A instruo signal dever incrementar o valor do semforo. Caso
haja
algum processo/thread na fila, o primeiro elemento da fila
dever ser retirado
e executado.
s i g n a l (S) :
S. v a l o r = S. va l o r + 1;
Se S. f i l a no est vazia Ento
Ret i ra processo / thread da f i l a e executao ;
Figura 12: Implementao semforo bloqueante - instruo

signal. Fonte: (SILBERSCHATZ;
A implementao de semforos com fila de espera pode resultar
em situao
de deadlock onde dois ou mais processos/threads estejam
esperando indefinidamente
por um evento que s possa ser acionado por um dos
processo/threads
em espera na fila (SILBERSCHATZ; GALVIN; GAGNE, 2009). Outro
problema,
est
relacionado
espera
por
tempo
indefinido
de
processos/threads em filas,
causando uma situao de inanio (SILBERSCHATZ; GALVIN;
GAGNE, 2009).
O bloqueio indefinido pode ocorrer se a fila de espera do
semforo for organizada
em ordem LIFO (Last In First Out) ou atravs de escalonamento
por prioridades.
Desta forma, deve-se adotar polticas de ordenao de filas que
evitem tais
situaes.
28
3.3.2 Monitor
Monitor uma primitiva de sincronizao de alto nvel, proposto
por C. A.
R. Hoare em 1974 (TANENBAUM; WOODHULL, 2008). Um
monitor um
conjunto de procedimentos, variveis e estruturas de dados,
agrupadas em um
tipo especial de mdulo ou pacote, conforme ilustrado na Figura
13. A estrutura
do tipo monitor define que somente um processo/thread por vez
possa estar
ativo dentro do monitor, desta forma, garantindo a propriedade
de excluso
mtua (SILBERSCHATZ; GALVIN; GAGNE, 2009).
Figura 13: Viso esquemtica de um monitor
O monitor uma abstrao de alto nvel pois implementado
pela linguagem
de
programao.
de
responsabilidade
do
compilador
implementar a excluso
mtua em entradas de monitor, e uma maneira comum
utilizar semforos ou
mutex. O programador apenas descreve quais sero os
procedimentos que faro
parte
do
monitor,
cabe
ao
compilador
preparar
os
procedimentos para excluso

mtua (TANENBAUM; WOODHULL, 2008).
Embora a implementao de monitores garanta uma maneira
simples de
obter a excluso mtua, se houver necessidade de que certas
sequncias de
eventos ocorram ou no, deve-se modificar o procedimento
vinculado a um
monitor inserindo variveis de condio, para essas controlarem

a ordem de
execuo dos eventos (TANENBAUM; WOODHULL, 2008). As
variveis de
condies so manipuladas por intermdio de duas operaes,
conhecidas como
wait e signal. A operao wait faz com que o processo/thread
seja colocado
em estado de espera na fila da condio associada, at que
algum outro
processo/thread sinalize com a operao signal que a condio
de espera foi
satisfeita,
liberando
um
processo/thread
da
fila.
Caso
operao signal seja

invocada e no haja nenhum processo/thread aguardando a
condio, nenhum
efeito surtir.
possvel que vrios processos/threads permaneam em
estado de espera,
aguardando a sinalizao de diversas condies. Para isso, o
monitor organiza
os
processos/threads
suspensos
em
filas
associadas
respectivas condies.
A execuo da instruo signal referente a uma condio libera
apenas um
29
nico processo/thread da fila de espera da condio associada,
baseandose
em algoritmos de escalonamento. Um processo/thread pode
executar um
procedimento de um monitor mesmo quando haja um ou mais
processos/threads
aguardando na fila de espera de condies, conforme ilustrado

pela Figura 14 .
Figura 14: Monitor com variveis de condio
Um exemplo de utilizao de monitores na programao pode
ser dado
atravs da linguagem Java, onde nessa linguagem todo objeto
possui um monitor
associado,
sendo
identificado
pela
palavra
synchronized
(DEITEL; DEITEL,
2005), conforme ilustrado pela Figura 15.
1
public class ContaBancaria {
pr ivate double saldo = 0;
3
4
public synchronized void deposi to ( double quant ia ) {
this . saldo = this . saldo + quant ia ;
} else {
System. out . p r i n t l n ("A quantia do depsito deve ser maior
que ZERO.") ;
9
10
11
12
public synchronized void saque ( double quant ia ) {
13
i f ( this . saldo quant ia > 0) {
14
this . saldo = this . saldo quant ia ;
15
} else {
16
System. out . p r i n t l n ("Saldo insuficiente para o valor de
saque desejado.") ;
17
18
19
Figura 15: Exemplo de cdigo em Java utilizando monitor

3.3.3 Memrias transacionais
O termo memria transacional foi cunhado em 1993 por Herlihy
e Moss para
designar: "uma nova arquitetura para microprocessadores que
objetiva tornar
a sincronizao livre de bloqueio to eficiente (e fcil de usar)

quanto tcnicas
30
convencionais baseadas em excluso mtua" (HERLIHY; MOSS,
1993). Este
termo define qualquer mecanismo de sincronizao que utilize o
conceito de
transao para coordenar acessos memria compartilhada.
A memria transacional usa como principal abstrao o
conceito de transao,
criada e desenvolvida no contexto de sistemas de banco de
dados (GRAY;
REUTER,
1993).
Nesse
domnio,
uma
transao
uma
sequncia finita de
instrues, sendo serializadas por uma thread, satisfazendo as
propriedades
ACID (Atomicidade, Consistncia, Isolamento e Durabilidade).
A
propriedade
de
atomicidade
define
que
as
instrues
pertencentes ao
escopo da transao sero todas efetivadas com sucesso ou
todas descartadas.
Quando a transao for efetivada com sucesso o resultado da
execuo
permanente, e diz-se que a transao sofreu commit. Quando
ocorrer falha na
transao,
diz-se
que
essa
sofreu
abort,
os
valores
pertencentes execuo
da transao sero descartados.
A propriedade de consistncia assegura a integridade dos dados,
garantindo
que uma transao levar o sistema de um estado consistente
(prtransao)
a outro estado consistente (ps-transao).
O isolamento significa que transaes concorrentes no podero

verificar
resultados intermedirios produzidos por outras transaes, de
modo que o
resultado de execuo de diversas transaes seja equivalente
ao resultado de
execuo dessas mesmas em ordem serial.
A propriedade de durabilidade indica que as mudanas efetivadas
por
transaes so permanentes e resistentes a eventuais falhas no
sistema.
O conceito de transao no contexto de memrias transacionais
basicamente
o mesmo, com exceo para a propriedade de durabilidade. O
conceito
de durabilidade pode ser ignorado em memrias transacionais,
pois em seu
contexto os dados sero armazenados em memria voltil, ao
contrrio de
sistemas de banco de dados onde os dados so armazenados
em memria
persistente.
Em relao ao uso de bloqueios, a memria transacional
apresenta as
seguintes vantagens (MCKENNEY et al., 2010):
_ Facilidade de programao: a programao torna-se mais fcil
porque o
programador no tem responsabilidade em como garantir a
sincronizao,
e sim em especificar quais blocos de cdigo devem ser
executados
atomicamente,
implementao do
cabendo
ao
sistema
transacional
mecanismo de sincronizao.
_ Escalabilidade: Transaes que acessem um mesmo dado para
leitura
podem ser executadas concorrentemente. Tambm podem ser
executadas
de modo paralelo as transaes que modifiquem partes
distintas de uma
mesma estrutura de dados. Essa caracterstica tem como
vantagem
garantir que mais desempenho seja obtido com o aumento do
nmero de
processadores porque o nvel de paralelismo exposto maior.
_
Composabilidade:
Transaes
suportam
naturalmente
composio
de cdigo. Para criar uma nova operao baseando-se em
outras j
existentes, deve-se invoc-las dentro de uma nova transao. O
sistema
transacional ir garantir que tais operaes sejam executadas
de forma
atmica.
31
A seguir, ser apresentado a memria transacional sob a
perspectiva do
programador, em relao linguagem e semntica.
3.3.3.1 Linguagem e semntica
Aspectos referentes linguagem e semntica so importantes
por indicarem
o grau de expressividade da linguagem e definir univocamente
o significado de
cada uma de suas construes (BALDASSIN, 2009).
No contexto de memrias transacionais, as seguintes trs
construes so
atualmente aceitas: atomic, retry e orElse.

Construo atomic
A construo atomic representa o bloco atmico, o qual
responsvel
por delimitar o escopo que deve ser executado por uma
transao (HARRIS;
FRASER, 2003). Uma grande vantagem do bloco atmico que
no
necessrio
criar
manualmente
variveis
especficas
para
controlar e bloquear a
seo crtica de um programa, diferentemente de outras
construes como locks.
O
sistema
transacional
ser
responsvel
por
garantir
sincronizao do bloco,
deixando a encargo do programador apenas especificar quais
sero os blocos
atmicos e no em como sincroniz-los.
Na Figura 16 mostra-se um exemplo de implementao do bloco
atmico,
sendo delimitado pela palavra atomic (linha 2 at linha 8).
1
public void deposi ta ( double quant ia ) {
atomic {
this . saldo = this . saldo + quant ia ; / / Seo Cr t i c a
} else {
System. out . p r i n t l n ("A quantia do depsito deve ser
maior que ZERO.") ;

7
Figura 16: Bloco atmico

A composio de transaes ilustrada na Figura 17, atravs de
um mtodo
que transfere um valor entre duas contas bancrias. Pelo fato
da operao ser
efetuada de forma atmica e em isolamento, garantido que

nenhuma outra
transao ver o estado intermedirio na qual o valor sacado de
uma conta
(linha 3) ainda no tenha sido depositado na outra (linha 4).
Caso haja falha
em alguma das operaes (saque ou deposito) o sistema
transacional abortar
toda
transao,
descartando
as
alteraes
em
ambas
operaes.
Construo retry
A construo retry define que a transao seja cancelada,
desfazendo
todas as aes intermedirias (HARRIS et al., 2005). Quando
algum dado
compartilhado
recentemente
acessado
pela
transao
modificado, a transao
re-executada. Por exemplo, suponha-se a remoo de
elemento de um buffer.
32
1
public void t r a n s f e r e n c i a ( ContaBancaria contaOrigem ,
ContaBancaria
contaDestino , Double quant ia ) {
2
atomic {
contaOrigem . saque ( quant ia ) ;
contaDest ino . deposi to ( quant ia ) ;
Figura 17: Composio em memria transacional

Sempre que um buffer estiver vazio a transao invoca a
construo retry,
fazendo com que a transao seja cancelada e re-executada
quando a varivel
itens for modificada por outro processo/thread.
Afim de comparar uma construo transacional com outra

abordagem de
programao, o mesmo exemplo de remoo de elemento de
um buffer ser
implementado em Java utilizando de monitores, conforme
mostra na Figura 19.
O uso da primitiva synchronized indica que o processo/thread
que invocar o
mtodo remover dever obter o bloqueio associado ao objeto
buffer, antes de
prosseguir com a operao de remoo. A aquisio e liberao
de bloqueios
implcita em Java, quando o mtodo for qualificado como
synchronized. O
mtodo wait serve para garantir que no seja removido um
elemento de um
buffer
vazio
mtodo
notifyAll
notifica
os
outros
processos/threads que um
elemento foi removido do buffer.
1
2
public int remover ( ) {
atomic {
i f ( i t e n s == 0)
retry;
i tens ;
return b u f f e r [ i t e n s ] ;
Figura 18: Remoo elemento de buffer codificada com a

construo retry.
Fonte: (RIGO; CENTODUCATTE; BALDASSIN, 2007)
1
2
public synchronized int remover ( ) {
int resul tado ;
while ( i t e n s == 0)
wai t ( ) ;
i tens ;
resul tado = b u f f e r [ i t e n s ] ;
notifyAll();
return resul tado ;
10
Figura 19: Remoo elemento de buffer codificada em Java com

monitor.
33
A partir dos dois exemplos mostrados nas Figuras 18 e 19,
observa-se um
problema
comum
com
bloqueios:
baixa
concorrncia
e,
respectivamente, baixo
desempenho. Como um bloqueio associado ao objeto buffer
adquirido ao
invocar o mtodo remover, qualquer outro mtodo do objeto
que eventualmente
seja invocado ser bloqueado at que o mtodo libere o
bloqueio. Ou seja, duas
ou mais operaes no acontecero concorrentemente no
buffer mesmo quando
h uma possibilidade de paralelismo. Por exemplo, possvel
que uma operao
de insero ocorra simultaneamente a uma de remoo se
ambas acessarem
elementos disjuntos no buffer. Portanto o uso de transaes
consegue explorar
mais paralelismo, pois a deteco de conflitos feita de forma
dinmica (em
tempo de execuo).
Construo orElse
A construo orElse permite que transaes sejam compostas
como alternativas
para execuo, significando que somente uma transao ser

executada
entre vrias (HARRIS et al., 2005).
Por exemplo, suponha-se um sistema que remova elementos de
um buffer.
O mtodo de remoo pode ser bloqueado (invocar retry) se o
buffer estiver
vazio, conforme mostrado na Figura 18. Uma implementao
possvel usando
orElse para esta situao mostrada na Figura 20. Nesta
implementao, o
sistema transacional tentar remover elementos entre dois
buffers. Caso o buffer
1 estiver vazio o sistema tentar remover o elemento do buffer
2. Caso os dois
buffers estiverem vazios, o bloco atmico ser bloqueado at
que ao menos um
dos buffers contenha um elemento para poder ser removido.
1
2
public void exemploOrElse ( ) {
atomic {
{ x = buf fer1 . remover ( ) ; }
orElse
{ x = buf fer2 . remover ( ) ; }
Figura
20:
Uso
da
construo
orElse.
Fonte:
(RIGO;
CENTODUCATTE;
BALDASSIN, 2007)
Nveis de isolamento
O nvel de isolamento est relacionado interao entre cdigo
transacional
e cdigo no transacional. Existem dois tipos de isolamento:
atomicidade forte
(strong
atomicity)
atomicidade
fraca
(weak
atomicity)
(BALDASSIN, 2009).
No
modelo
com
atomicidade forte o
acesso
um
dado
compartilhado fora de
uma transao consistente com os acessos efetuados ao
mesmo dado dentro
da transao. Em contrapartida, no modelo com atomicidade fraca
o acesso a
um mesmo dado compartilhado, dentro e fora de uma
transao, causa condio
de corrida e portanto o resultado no-determinstico.
34
3.3.3.2 Implementao
Um
sistema
de
memria
transacional
deve
garantir
consistncia e integridade
de execues das transaes, satisfazendo as propriedades de
atomicidade,
consistncia e isolamento, descritas anteriormente.
As implementaes so construdas com dois mecanismos
chaves: versionamento
de
dados
deteco/resoluo
de
conflitos
(RIGO;
CENTODUCATTE;
BALDASSIN, 2007).
Versionamento de dados
O versionamento de dados lida com o gerenciamento das
diferentes verses
dos dados (originais e especulativas) acessados por uma
transao. A verso
original corresponde ao valor do dado antes do incio da
transao. A verso
especulativa representa o valor intermedirio sendo trabalhado
pela transao.
Caso a transao seja efetivada, os valores especulativos

tornam-se os valores
correntes e so armazenados, e os valores originais so
descartados. Do
contrrio,
descarta-se
os
especulativos
mantm-se
os
originais (BALDASSIN,
2009).
Existem
duas
formas
de
versionamento
de
dados:
adiantado/direto (direct
update ou eager versioning) e atrasado/diferido (deferred update
ou lazy
versioning) (RIGO; CENTODUCATTE; BALDASSIN, 2007).
No versionamento de dados adiantado, os valores so armazenados
diretamente na memria, enquanto que os valores antigos so
armazenados em
um undo log. No caso de uma transao falhar, os dados que
foram gravados na
memria inicialmente devero ser convertidos para suas
verses antigas, atravs
do undo log.
No versionamento de dados atrasado, o armazenamento de novos
dados
realizado em um buffer local, e a memria continua com os
valores antigos. Os
dados so transferidos do buffer para a memria somente
quando a transao
for confirmada.
Ilustra-se na Figura 21 um exemplo com ambos tipos de
versionamento de
dados. Inicialmente, o contedo da varivel X na memria
corresponde ao valor
100 e os respectivos undo log e buffer esto vazios. Quando
uma transao
atribui o valor 77 varivel X, o versionamento adiantado altera

imediatamente o
contedo da memria e armazena o valor antigo localmente
(undo log), enquanto
o versionamento atrasado somente necessita salvar o novo
valor em memria
local (buffer ). No momento da efetivao da transao, a nica
ao necessria
no versionamento adiantado invalidar o undo log, pois o dado
novo j est na
memria. J o versionamento atrasado precisa primeiramente
mover o valor
armazenado localmente para a memria do sistema. Uma
situao inversa
acontece em caso de cancelamento da transao. Nesse caso, o
versionamento
adiantado
precisa
restaurar
as
mudanas
efetuadas
na
memria, movendo para

esta o valor antigo presente no undo log. Com o versionamento
atrasado s
necessrio descartar os valores especulativos.
Como pode ser observado na Figura 21, conclui-se que o
versionamento
adiantado torna-se mais eficiente em casos em que a transao
confirmada,
pois os valores corretos j esto na memria. Por outro lado,
quando a transao
cancelada, deve-se restaurar os valores corretos para a
memria, que esto
35
armazenados no undo log. No versionamento atrasado a
situao oposta,
visto que transaes confirmadas necessitam transferir os

dados do buffer para
a
memria,
enquanto
que
transaes
canceladas
no
necessitam de nenhuma
operao.
Figura 21: Exemplo ilustrando versionamento adiantado (a) e
atrasado (b).
Fonte: (BALDASSIN, 2009)
Deteco/Resoluo de conflitos
Diz-se que houve conflito entre duas ou mais transaes
quando essas
acessam o mesmo dado compartilhado e um dos acessos de
escrita (BALDASSIN,
2009). O sistema transacional efetua a deteco de conflitos
baseandose
na granularidade de deteco de conflitos. Essa granularidade
pode ser
em
trs
nveis:
objeto,
palavra
linha
de
cache
(RIGO;
CENTODUCATTE;
BALDASSIN, 2007). A granularidade por nvel de objetos pode
reduzir o
overhead em termos de espao e tempo para deteco de
conflitos. No entanto,
esse nvel permite detectar falsos conflitos, ou seja, casos em
que o sistema
detectar
conflitos
quando
duas
transaes
operam
em
diferentes partes de um
mesmo objeto. A granularidade por nvel de palavras elimina a
deteco de
falsos conflitos, por outro lado, necessita-se de maior custo e
espao para a
deteco. A granularidade por nvel de linha de cache prov um
acordo entre
a frequncia de deteco de falsos conflitos e o overhead em

termos de tempo
e espao. No entanto, necessita-se de alteraes na estrutura
de hardware para
prover a cache transacional, alterando seu protocolo de
coerncia.
Assim como no versionamento de dados, h dois modos de
deteco de
conflitos: adiantado/pessimista (pessimistic ou eager conflict
detection) e atrasado/
otimista
(optimistc
ou
lazy
conflict
detection)
(RIGO;
CENTODUCATTE;
BALDASSIN, 2007).
No modo de deteco de conflitos adiantado, o conflito detectado
no
momento em que uma posio de memria acessada. Desta
forma podese
evitar que uma transao execute desnecessariamente, mas
por outro lado,
pode cancelar transaes, dependendo do progresso de outras,
poderiam ser
36
confirmadas com sucesso. Para exemplificar a deteco de
conflitos de forma
adiantada,
os
cenrios
mostrados
na
Figura
22
sero
considerados. No caso
1, T1 e T2 manipulam conjuntos de dados disjuntos e portanto
no h nenhum
conflito. No caso 2 tem-se uma operao de escrita depois de
uma leitura. A
transao que escreveu (T2) faz com que a outra transao (T1)
seja cencelada.
O caso 3 mostra a situao em que, aps ser cancelada, T1

volta a executar
e por sua vez cancela a transao T2. Nesse exemplo, pode-se
notar que as
transaes T1 e T2 esto em estado de livelock, desta forma, a
efetivao de
tais transaes indefinida.
Figura 22: Deteco de conflitos em modo adiantado em
cenrios transacionais.
Na deteco atrasada o conflito detectado somente no
momento de
efetivao da transao. Desta forma, essa abordagem permite
que transaes
conflitantes prossigam na esperana do conflito no se efetivar
de fato.
De modo a exemplificar a deteco de conflitos de forma
atrasada, os
cenrios mostrados na Figura 23 sero considerados. No caso 1,
as transaes
acessam um conjunto de dados disjuntos, no ocasionando
conflitos. No caso
2, T2 l uma varivel escrita por T1. Quando T1 sofre
efetivao, T2 nota o
conflito e reiniciada. No caso 3 no ocorre nenhum conflito,
pois T1 apenas l
uma varivel que T2 est escrevendo e esta sofre efetivao
aps T1. O caso 4
mostra a situao em que, aps ser cancelada, T1 volta a
executar. No entanto,
diferentemente da deteco adiantada, este caso no gera
situao de livelock,
porm, poderia acontecer situao de starvation. Se T1 fosse

muito longa essa
poderia ser sempre cancelada por outras transaes e nunca
conseguir efetivar
suas alteraes.
O gerenciador de conteno o componente do sistema
transacional responsvel
por resolver os conflitos dentre as transaes concorrentes. A
resoluo de
conflitos deve ser efetuada de tal forma a garantir progresso do
sistema, ou seja,
deve evitar starvation e livelock (BALDASSIN, 2009). Algumas
propostas de TM
possuem um mtodo fixo para gerenciamento de conteno, ao
passo que outras
propostas tratam o problema como um aspecto modular do
sistema, podendo ser
alterado para melhorar o desempenho de um programa sob
determinada carga
de trabalho (KRONBAUER; RIGO, 2009).
37
Figura 23: Deteco de conflitos em modo atrasado em cenrios
transacionais.
A escolha do gerenciador de conteno pode influenciar no
desempenho
e consumo de energia de memrias transacionais, conforme
ser mostrado
no Captulo 4. Porm, no existe um consenso na comunidade
de TM sobre
qual estratgia para deteco/resoluo de conflitos a mais
efetiva, pois
uma estratgia pode funcionar bem para algumas aplicaes

mas no para
outras (BALDASSIN, 2009).
3.3.3.3 Modelos de memrias transacionais
As implementaes de TM so comumente divididas em trs
modelos:
hardware,
software,
hbrida
(BALDASSIN,
2009).
As
implementaes nas
trs abordagens devem prover o versionamento dos dados
manipulados pelas
transaes
de
forma
atmica
isolada,
efetuar
deteco/resoluo de
conflitos entre transaes.
Memria Transacional em Hardware
As implementaes de memrias transacionais em hardware
(HTM) usualmente
fazem o versionamento de dados e deteco de conflitos
atravs
modificaes
extenses
em
alguns
componentes
da
arquitetura computacional
(BALDASSIN, 2009).
A primeira implementao de HTM foi desenvolvida por Herlihy
e Moss em
1993 (HERLIHY; MOSS, 1993). Para dar suporte a transaes,
Herlihy e Moss
estenderam a arquitetura do conjunto de instrues de um
processador base
com 6 novas instrues, adicionaram uma cache especial,
chamada de cache
transacional, e alteraram o protocolo de coerncia.
Vrias abordagens de HTM foram desenvolvidas aps o modelo
descrito por
Herlihy e Moss, procurando suprir as principais deficincias da

proposta inicial,
a qual restringia o nmero de posies acessadas pela
transao (espao)
e a durao em que a transao poderia estar ativa. As
principais so:
TCC (Transactional Coherence and Consistency) (HAMMOND et
al., 2004),
UTM (Unbounded Transactional Memory) (ANANIAN et al., 2005),
VTM (Virtual
Transactional Memory) (RAJWAR; HERLIHY; LAI, 2005), LogTM
(Log-based
Transactional Memory) (MOORE et al., 2006), PTM (Page-based
Transactional
38
Memory) (CHUANG et al., 2006), OneTM (BLUNDELL et al., 2007)
e MetaTM
(RAMADAN et al., 2007). Essas propostas tm suporte para
virtualizao
de espao e tempo, diferenciando-se entre si pelo hardware
extra exigido e
estratgia adotada para versionamento e controle de conflitos.
As
implementaes
em
hardware
tm
como
principais
caractersticas garantir
atomicidade forte como nvel de isolamento e granularidade por
linha de cache.
A principal vantagem de HTM o desempenho, pelo fato de
implementar as
transaes
diretamente
em
hardware.
No
entanto,
as
implementaes em
hardware ainda so consideradas complexas, tornando invivel
a adoo e
implementao
efetiva
em
algum
processador
comercial
(BALDASSIN, 2009).
Memria Transacional em Software
O modelo em software implementa as transaes puramente
em software.
Como
vantagem
dessa
abordagem,
tem-se
uma
maior
flexibilidade na implementao
aliada execuo em mquinas atuais e subsequentemente a
portabilidade deste modelo, visto que alteraes na arquitetura
computacional
no fazem-se necessrias (RIGO; CENTODUCATTE; BALDASSIN,
2007).
O termo Memria Transacional em Software (STM) foi cunhado
por Shavit
e Touitou em 1995 (SHAVIT; TOUITOU, 1995), propondo uma
alternativa em
software ao mecanismo em hardware de Herlihy e Moss
(HERLIHY; MOSS,
1993), de 1993. A implementao proposta mantm para cada
palavra em
memria compartilhada um registro de posse, que aponta para
o registro da
transao detentora da palavra. O processo de efetivao das
transaes
baseia-se na aquisio de posse de todas as palavras a serem
alteradas,
efetuao das alteraes e liberao da posse. Um conflito
acontece caso
alguma palavra j tenha sido adquirida por outra transao.
Os sistemas de memria transacional em software usam
barreiras de leitura
e escrita para interceptar os acessos aos dados compartilhados
e manter os
conjuntos de leitura e escrita (BALDASSIN, 2009). Existem dois

tipos principais
de implementaes: no-bloqueantes e bloqueantes.
As primeiras implementaes de STM so no-bloqueantes,
entre as principais
esto: DSTM (Dynamic STM) (HERLIHY et al., 2003), WSTM
(Wordbased
STM) (HARRIS; FRASER, 2003), OSTM (Object-based STM)
(FRASER,
2004), HaskellTM (HARRIS et al., 2005), ASTM (Adaptive STM)
(MARATHE;
Scherer III; SCOTT, 2005) e RSTM (Rochester STM) (MARATHE et
al., 2006).
Especificamente, DSTM, ASTM e RSTM so livres de obstruo,
enquanto
WSTM,
OSTM
HaskellTM
so
livres
de
trava.
Nas
implementaes livres de
obstruo, o gerenciador de conteno tem um papel vital, pois
o componente
transacional responsvel por determinar o progresso do sistema
em situaes
de conflitos. A maioria dessas implementaes trabalham com
granularidade em
nvel
de
objeto,
exceto
WSTM
HaskellTM
que
usam
granularidade em nvel de
palavra.
Constatou-se
atravs
de
pesquisas
que
as
abordagens
transacionais em
software no-bloqueantes apresentam baixo desempenho, se
comparadas
utilizao de bloqueios explcitos (ENNALS, 2006). A partir desse
importante
resultado a maioria das implementaes propostas passaram a

utilizar locks,
de maneira implcita. Em especial, foram apresentadas: McRTSTM (Multi39
core RunTime STM) pela Intel (SAHA et al., 2006), Bartok-STM
pela Microsoft
(HARRIS et al., 2006), TL2 (Transactional Locking II) pela Sun
(DICE;
SHALEV; SHAVIT, 2006), TinySTM pelas universidades de
Neuchtel e de
Dresden (FELBER; FETZER; RIEGEL, 2008) e SwissTM pela Escola
Politcnica
Federal de Lausana (DRAGOJEVIC; GUERRAOUI; KAPALKA, 2009).
As
diversas
implementaes
de
STM
se
diferenciam
principalmente pela
granularidade de acesso permitido (palavra ou objeto), e pela
estratgia de
versionamento de dados, deteco e resoluo de conflitos
(BALDASSIN, 2009).
Ao contrrio de HTM, a maioria das implementaes em
software garantem
apenas atomicidade fraca como nvel de isolamento, devido a
motivos de
desempenho, pois garantir atomicidade forte exigiria incluir
barreiras tambm em
cdigo no transacional (BALDASSIN, 2009).
Memria Transacional Hbrida
A abordagem hbrida busca combinar os modelos de software e
hardware
com intuito de obter melhor resultado com a unio das duas
abordagens.
Nessa abordagem, transaes podem ser executadas em um
dois modos: em
hardware, com alto desempenho, ou software, com ilimitados

recursos (RIGO;
CENTODUCATTE; BALDASSIN, 2007).
Nas primeiras implementaes de memrias transacionais
hbridas as transaes
so iniciadas em modo de hardware, mas se os recursos de
hardware forem
exauridos a transao poder ser reiniciada em modo de
software (DAMRON
et al., 2006) (KUMAR et al., 2006). O grande desafio nessa
abordagem quando
existem transaes concorrentes executando tanto em modo de
hardware quanto
em modo de software. Contornar esse problema geralmente
requer solues que
tornam as transaes em hardware mais lentas do que o
desejado (BALDASSIN,
2009).
Posteriormente, as propostas de TM hbridas basearam-se na
acelerao do
software atravs do suporte executivo em hardware (SAHA;
ADL-TABATABAI;
JACOBSON, 2006) (SHRIRAMAN et al., 2007) (MINH et al., 2007)
(SHRIRAMAN;
DWARKADAS; SCOTT, 2008). A principal caracterstica dessas
propostas
que as transaes so sempre executadas em modo de
software, mas usam o
hardware
para
acelerar
tarefas
crticas.
Por
exemplo,
validao das transaes

reconhecidamente um gargalo na maioria das STMs. Uma
soluo nas
abordagens hbridas seria adicionar hardware para acelerar

essa tarefa, como
feito por Saha et al. (SAHA; ADL-TABATABAI; JACOBSON, 2006).
A grande
vantagem que o hardware adicionado no especfico para
TM, podendo ser
potencialmente usado em outras tarefas (BALDASSIN, 2009).

Este Captulo apresentou os principais conceitos relacionados
comunicao
e sincronizao em sistemas concorrentes, em ambiente de
memria
compartilhada. Foram apresentados os problemas que podem
ocorrer durante
a comunicao entre fluxo de execues de sistemas, e os
mecanismos de
sincronizao, que visam garantir a corretude das execues
concorrentes.
Mostrou-se que mecanismos de sincronizao baseados em
bloqueios (locks)
40
so fceis de usar em muitos casos, e consequentemente so
muito utilizado,
porm, se no empregados corretamente, podem apresentar
uma srie de
problemas,
podendo
levar
sistema
um
estado
de
instabilidade. O mecanismo
de sincronizao por memrias transacionais garante maior
abstrao na codificao
de programas paralelos, pois tira da responsabilidade do
programador o
modo como as sincronizaes sero feitas, ficando a encargo do
sistema que
implementa as memrias transacionais garantir a sincronizao

em baixo nvel.
Por implementar as sincronizaes em baixo nvel, o sistema
transacional facilita
a codificao de programas paralelos, alm de suprir as
dificuldades e limitaes
encontradas no uso de locks.
Em relao as memrias transacionais, mostrou-se que as
implementaes
em
hardware
(HTM)
tm
como
principal
vantagem
desempenho, por
implementarem o suporte executivo diretamente em hardware,
a partir de
modificaes na arquitetura computacional. No entanto, este
modelo complexo
de ser projetado, dificultando assim, a adoo e implementao
efetiva em
processadores
comerciais.
Por
outro
lado,
embora
as
implementaes em
software (STM) apresentem desempenho inferior em relao
HTM, as STM
tm como principais vantagens a flexibilidade e portabilidade
da implementao,
pois
essas
podem
ser
executadas
diretamente
em
processadores atuais, em
consequncia, so atualmente alvo de muita pesquisa.
4 TRABALHOS RELACIONADOS
Este Captulo apresenta os principais trabalhos que levam em
considerao
a
medio
do
consumo
de
energia
e/ou
desempenho,
relacionados aos mecanismos

de sincronizao em ambiente de memria compartilhada,
descritos no
Captulo anterior.
4.1 Reduzindo o consumo de energia em um sistema

multiprocessado
usando HTM
O trabalho de Moreshet, Bahar e Herlihy (2005) avalia o
consumo de energia
de HTM em comparao locks (spinlock), sendo pioneiro em
avaliar o consumo
energtico em HTM.
Sua implementao baseia-se no modelo original de HTM
(HERLIHY; MOSS,
1993), no qual h uma cache transacional completamente
associativa para
armazenar os valores especulativos. Utiliza a plataforma de
simulao SIMICS
(MAGNUSSON et al., 2002) para modelar um sistema com
processadores
UltraSparc II conectados por barramento, assumindo dados de
energia e latncia
para
uma
memria
compartilhada
off-chip,
sistema
operacional Linux.
Duas diferentes abordagens para a HTM utilizada foram
experimentadas, na
qual, a diferena entre ambas est no mtodo utilizado para
manipulao de
conflitos em transaes. A primeira abordagem padro da
HTM utilizada, reexecuta
as transaes conflitantes em paralelo (baseado em backoff
randmico).
A segunda, foi proposta pelos prprios autores, sendo um
mecanismo para
execuo de modo serial de todas transaes pendentes
durante o o conflito.
Atravs dos resultados obtidos neste trabalho mostrou-se que a

verso utilizando
locks consumiu 10x mais energia que as abordagens de HTM
utilizadas.
Tal
resultado
deve-se
significativa
frao
de
energia
consumida pela hierarquia

de memria. Em relao s HTM utilizadas, a que utilizou a
execuo serial
para tratamento de conflitos mostrou-se mais eficiente em
termos de energia.
No entanto, esta uma abordagem pessimista, na qual h uma
conteno do
paralelismo.
Embora os resultados obtidos neste trabalho mostram que HTM
eficiente
em termos de consumo de energia, o trabalho apresentou
alguns problemas
que tornam seus resultados pouco convincentes. Apenas um
microbenchmark
(desenvolvido
pelos
prprios
autores)
com
apenas
uma
configurao do sistema
(quatro processadores) utilizado para os experimentos. E, no
descrito como
implementado
mecanismo
de
execuo
serial
das
transaes conflitantes.
42
4.2 HTM x locks: uma comparao de desempenho e

consumo
de energia
O trabalho de Moreshet, Bahar e Herlihy (2006) apresenta uma
extenso do
trabalho
de
Moreshet,
anteriormente. Utilizando
Bahar
Herlihy
(2005),
descrito
a mesma HTM e plataforma de simulao, avalia o consumo de

energia e
desempenho de HTM em comparao locks (spinlock) atravs
de quatros
aplicaes do benchmark SPLASH-2 (WOO et al., 1995).
Neste trabalho apresentado maiores detalhes em relao
execuo serial
das transaes conflitantes, visto que no trabalho anterior
apenas foi citado esse
novo mecanismo. Com o sistema transacional de execuo
serial, um conflito
ainda resulta em retornar ao estado anterior. No entanto,
durante alta conteno,
em vez de re-executar as transaes depois do conflito, o
sistema transacional ir
esperar uma transao completar antes de outra comear sua
execuo. Aps o
perodo conflitante, o sistema transacional voltar a emisso de
transaes em
paralelo.
Inicialmente, constatou-se atravs dos resultados obtidos no
benchmark
SPLASH-2 que na maioria das aplicaes onde substitui-se os
locks por
transaes, reduziu-se os acessos cache e a memria
principal, reduzindo
assim o consumo de energia e maximizando a performance.
Entretanto,
por considerar que as aplicaes do SPLASH-2 possuem taxas
de conflitos
baixa,
foi
utilizado
configuraes para simular
um
microbenchmark,
com
duas
diferentes cenrios de conflitos. Nas duas configuraes do

microbenchmark,
ambas implementaes de memria transacional (backoff e
serial) superaram
em termos de desempenho e eficincia energtica verso
utilizando locks,
cerca de 10x mais, no melhor caso.
Em uma das configuraes do microbenchmark, a memria
transacional
utilizando-se da execuo serial para os casos de conflito
superou em termos
de performance e eficincia energtica a memria transacional
que utilizou a
tcnica de backoff para conflitos. Porm, em outra configurao,
a verso
transacional serial mostrou-se ligeiramente inferior em relao
verso transacional
utilizando backoff, em termos de desempenho. Desta forma, o
modo de
execuo
serial
das
transaes
conflitantes
mostra-se
conservador, incorrendo
em penalidades no desempenho.
Atravs dos resultados mostrados neste trabalho verificou-se
que a abordagem
de HTM promissora em termos de desempenho e energia. A
execuo
serial para transaes conflitantes em ambientes de alta
conteno eficiente
em
termos
de
energia,
porm,
para
outros
casos,
produtividade do sistema
pode ser reduzida. No entanto, so dados poucos detalhes em
relao ao
microbenchmark e suas duas configuraes e a avaliao do

modo serial
feita somente neste microbenchmark, tornando novamente os
resultados pouco
convincentes.
4.3 McRT-STM x locks: uma comparao de desempenho

No trabalho de Saha et al (2006) mostrado um estudo de
avaliao de
desempenho entre a implementao McRT-STM e locks.
Dois experimentos com base em aplicaes diferentes foram
realizados. No
43
primeiro,
utilizou-se
de
estruturas
de
dados
comumente
utilizadas em muitas
aplicaes: hashtable, rvore de pesquisa binria, rvore B e
lista ligada.
No segundo, avaliou-se o desempenho de STM e locks em uma
aplicao
no sinttica, utilizando-se da aplicao Sendmail como base.
Utilizou-se da
plataforma IBM X Series 445 SMP com 16 processadores Xeon
com 2.2 GHz
para execuo das aplicaes.
Para o primeiro experimento, as seguintes constataes podem
ser feitas,
com base nos resultados obtidos. Na aplicao hashtable,
observou-se atravs
dos resultados que a verso de STM inicialmente (utilizando 1
processador)
obtm
menor
performance
em
comparao
as
duas
implementaes de locks
(gro fino e gro grosso). No entanto, conforme aumentou-se o
nmero de
processadores, o desempenho da STM aproximou-se da verso

verso de locks
que obteve maior desempenho (gro fino). Na utilizao de 16
processadores, a
STM foi cerca de 1.8x menos eficiente em termos
de
performance em relao
locks (gro fino). Na aplicao rvore de pesquisa binria
balanceada, verificouse
que a STM obtm melhor desempenho em comparao locks
quando a
proporo de atualizaes baixa. Contudo, para altas taxas de
atualizao,
a STM apresentou desempenho ineficiente. Isto porque o
balanceamento da
rvore propaga mudanas em toda rvore e aumenta o nmero
de cancelamento
das transaes. E, o balanceamento propaga mudanas na raiz
da rvore,
limitando a concorrncia. Na utilizao da rvore de pesquisa
binria sem
balanceamento observou-se que a STM apresentou melhor
desempenho em
comparao locks, mesmo com altas taxas de atualizao. Na
rvore B, a
STM mostrou melhor desempenho em comparao locks (gro
fino e gro
grosso) mesmo com altas taxas de atualizaes, devido a
rvore B resultar em
poucos cancelamentos de transaes. Na aplicao lista ligada
classificada, o
desempenho da STM variou conforme o nmero de atualizaes
na lista. Com
baixas
taxas
de
atualizao,
STM
apresentou
melhor
desempenho, mas com

o
aumento
de
atualizaes,
desempenho
torna-se
ligeiramente inferior a locks,

devido ao aumento do nmero de transaes canceladas. Na
lista ligada no
classificada, a memria transacional apresentou desempenho
inferior locks,
devido a todas inseres serem feitas na frente da lista, no
fornecendo desta
forma
nenhuma
simultaneidade
para
as
operaes
de
atualizao. Os resultados
obtidos para as aplicaes lista ligada e rvore de pesquisa
binria mostraram a
importncia de um bom gerenciador de conteno no sistema
transacional, visto
que a STM apresentou desempenho inferior em relao locks,
em cenrio de
alta conteno.
Em relao ao segundo experimento, verificou-se que a
aplicao Sendmail
(baseada em locks) gasta cerca de 10% de seu tempo de
execuo em
sees crticas, assim, devido a seo crtica representar um
tempo significante,
analisou-se a utilizao de STM na aplicao, buscando reduo
de tempo de
execuo para a seo crtica. Os testes foram realizados
utilizando-se de uma
a 8 threads para cada abordagem. Em todos os casos, verificouse que a STM
se equiparou em termos de desempenho em relao verso
utilizando locks.
Esse resultado preliminar fornece evidncias que at mesmo

para aplicaes
comerciais, a STM e locks so semelhantes em termos de
desempenho.
44
4.4 Caracterizando o consumo de energia em STM

O trabalho de Baldassin et al (2009) pioneiro em caracterizar
o consumo de
energia em STM.
O processo de caracterizao foi conduzido em um ambiente
simulado
amplamente usado na literatura, conhecido como MPARM
(LOGHI; PONCINO;
BENINI,
2004).
Em
relao
plataforma
utilizada
duas
observaes fazemse
necessria. Primeiramente, as memrias empregadas (tanto
privada como
compartilhada) so baseadas na tecnologia SRAM (Static
Random Access
Memory). Segundo, os acessos feitos a memria compartilhada
no so retidos
na cache, visto que a implementao do barramento usado no
possui suporte
para coerncia de cache.
As aplicaes utilizadas na caracterizao fazem parte do
pacote de benchmark
STAMP
(CAO
MINH
et
al.,
2008),
disponibilizado
pela
Universidade
de Standford. Foram utilizadas as 8 aplicaes presentes no
pacote, com
diferentes configuraes, visando representar diversos cenrios
transacionais
com diferentes tamanhos de transao, tempos em transao,

tamanho do
conjunto de leitura e escrita, e graus de conteno. De igual
modo, uma verso
sequencial (no utilizando-se de transaes) ser executada
para comparao
STM.
A implementao da STM utilizada nos experimentos foi a TL2
(DICE;
SHALEV; SHAVIT, 2006), configurada de dois modos (ambos
usados nos
experimentos): TL2-lazy (versionamento atrasado) e TL2-eager
(versionamento
adiantado). Duas estratgias do gerenciamento de conteno
so providas,
baseadas na tcnica conhecida como backoff : aps trs
cancelamentos consecutivos,
uma transao postergada por um tempo (exponencial ou
linear)
proporcional ao nmero de cancelamentos.
O procedimento de medio de energia foi dividido pelos
componentes
bsicos de uma STM, possibilitando assim, avaliar quais os
elementos mais
custosos e orientar o projeto do algoritmo de forma a otimiz-lo.
Os experimentos realizados foram executados na plataforma de
simulao
com dois cenrios diferentes. Inicialmente, utilizou-se de
apenas 1 processador
nos experimentos, e posteriormente, para que os custos
devidos aos cancelamentos
das transaes fossem contabilizados, foram utilizados 8
processadores.
Mostrou-se atravs dos resultados dos experimentos que a

implementao
que utiliza versionamento adiantado (TL2-eager) tem um custo
de energia
ligeiramente menor do que a tcnica com versionamento
atrasado (TL2-lazy). No
entanto, em relao a execuo sequencial, para algumas
aplicaes, o custo
total introduzido pelas transaes pode chegar perto de 5x, na
utilizao de 1
processador.
Na utilizao de 8 processadores, alm das diferentes tcnicas
de versionamento
de dados, as duas configuraes de backoff (exponencial e
linear)
foram contabilizadas. De modo geral, observou-se que para
aplicaes com
alta taxa de cancelamento, nos casos em que o esquema de
espera linear
usado, o custo de cancelamentos domina. Porm, no emprego
do tempo de
espera exponencial, o custo de backoff passa a prevalecer. Em
uma aplicao
especfica do pacote de benchmark, utilizando-se de TL2-lazy e
tempo de espera
exponencial, o custo total de energia chega a cerca de 50x o do
caso sequencial.
Com base nos resultados providos pela caracterizao, devido
ao alto
45
consumo de energia em casos de alta conteno, os autores
propuseram a
utilizao de uma estratgia que visa reduzir o consumo em

casos em que
estados de espera so induzidos por cancelamentos de
transaes, podendo
ser usada em qualquer STM na qual o gerenciador de conteno
adote polticas
de resoluo de conflitos baseada em espera. A estratgia
proposta baseada
na tcnica conhecida como DVFS (KAXIRAS; MARTONOSI, 2008).
A estratgia funciona da seguinte maneira: antes de entrar no
modo de
backoff, o processador correspondente colocado em modo de
baixo consumo
de potncia, atravs da reduo de sua frequncia e voltagem.
O processador
ento cumpre seu tempo em estado de espera (linear ou
exponencial) em modo
de baixa potncia. Quando o tempo de backoff termina, a
frequncia e voltagem
originais
so
restauradas.
custo
para
alternncia
em
diferentes estados no
processador rpido, requerendo apenas 1 ciclo por mudana,
na plataforma
utilizada.
Os experimentos utilizando-se da estratgia descrita, como
resultado, obtiveram
uma reduo efetiva do consumo de energia para as aplicaes
com alto
grau de conteno, em mdia de 45%, chegando a 87% de
reduo para uma
aplicao especfica.
4.5 Avaliao de desempenho em gerenciadores de

conteno
com STM
O trabalho de Kronbauer e Rigo (2009) avalia diferentes
estratgias de gerenciadores
de
conteno
em
STM,
em
termos
de
desempenho.
Especificamente,
os
seguintes
gerenciadores
foram
avaliados:
Aggressive,
Eruption, Greedy,
Highlander, Karma, Killblocked, Polka, Polkaruption e Whpolka.
Utilizou-se da verso 3 da biblioteca RSTM, em dois modos:
bloqueante e
no bloqueante. Foram realizadas algumas modificaes na
biblioteca de modo
a permitir que diferentes gerenciadores de conteno possam
ser associados a
diferentes transaes ou a diferentes objetos transacionais.
Precisamente, foi
alterado a macro que delimita o incio da transao, fazendo
com que recebesse
como parmetro um valor enumerado capaz de identificar o
gerenciador de
conteno a ser usado. O gerenciador pode desta forma ser
associado ao objeto
que encapsula a estrutura de dados transacional, e diferentes
gerenciadores de
conteno podem ser associados a diferentes estruturas de
dados ou mesmo a
diferentes operaes em uma mesma estrutura de dados.
Trs diferentes sistemas computacionais foram utilizadas para
as execues.
O primeiro, um sistema baseado no processador Intel Core 2
Duo a 2.8 GHz, com
2 GB de memria RAM. O segundo um sistema baseado no
processador Intel
Core 2 Quad, a 2.4 GHz e com 4 GB de RAM. O terceiro, um

sistema com dois
processadores Intel Core 2 Quad a 2 GHz e 4 GB de RAM. Todos
os sistemas
utilizaram como sistema operacional uma distribuio Linux
padro (kernel 2.6).
Necessitou-se portar a biblioteca RSTM para arquiteturas x86 de
32 bits, pois a
verso 3 da RSTM somente tem suporte para a plataforma
SPARC.
Utilizou-se da implementao de rvores balanceadas do tipo
vermelha-epreta,
do benchmark disponvel junto a implementao original da
biblioteca
RSTM, como aplicao base para os experimentos. O nmero de
threads
foi variado ao longo das execues do benchmark, de uma
thread at o
46
nmero de threads de execuo igual a quatro vezes o nmero
de ncleos
de processamento no sistema. Para assegurar diferentes
padres de acesso
a diferentes estruturas de dados, as rvores foram geradas de
maneira a simular
diferentes cenrios (baixa, mista e alta conteno). Os tipos de
operaes
nas rvores foram particionados igualmente, sendo um tero
buscas, um tero
inseres e um tero remoes.
Algumas afirmaes podem ser feitas com base nos resultado
obtidos. Para
o sistema Intel Core 2 Duo, o gerenciador de conteno

Aggressive foi o que
apresentou melhores resultados, tanto no cenrio de alta
quanto no cenrio de
baixa conteno, na utilizao de 4 ou mais threads. Para o
sistema Intel Core
2
Quad
verificou-se
que
sob
alta
conteno,
quatro
gerenciadores apresentaram
o melhor desempenho. Estes foram Killblocked, Karma, Eruption
e Whpolka.
Sob baixa conteno, o gerenciador Aggressive ofereceu o
melhor desempenho
de modo geral, especialmente quando o nmero de threads
excede o nmero
de
ncleos
de
processamento.
Sob
conteno
mista,
gerenciador Aggressive
novamente apresentou o melhor resultado. No sistema Intel
Dual Core 2 Quad,
o gerenciador Killblocked apresentou em todos os casos o
melhor desempenho,
tanto em ambientes de alta como baixa conteno. De maneira
geral, a
implementao no-bloqueante da STM utilizada apresentou-se
ligeiramente
inferior em relao a verso bloqueante, em termos de
performance.
Notou-se atravs dos resultados obtidos que no h um
gerenciador de
conteno
ideal
ser
utilizado
como
escolha
padro,
reafirmando os resultados
encontrados em (GUERRAOUI; HERLIHY; POCHON, 2005). Porm,
verificouse
que a escolha ideal do gerenciador de conteno varia

conforme o nvel
de conteno e plataforma de hardware. Mostrou-se neste
trabalho que os
gerenciadores
de
conteno
representam
uma
rea
interessante para a busca

pela melhoria de desempenho, no entanto, novos fatores
tambm devem ser
considerados na avaliao destes, como o consumo de energia.
4.6 STM x locks: uma perspectiva de desempenho e

consumo
de energia
O trabalho de Klein et al (2010) avalia o consumo de energia e
desempenho
de STM em comparao locks, utilizando a mesma plataforma
de simulao,
pacote de benchmark, metodologia e implementao de STM,
apresentada no
trabalho de Baldassin et al (2009), descrito na seo anterior.
As aplicaes baseadas em locks foram implementadas como
um tpico
mecanismo de spinlock. Foi substitudo as marcaes de
transaes pelas
operaes de aquisio e liberao do lock global, pois o
benchmark utilizado
no prove uma verso baseada em locks para as aplicaes.
Os experimentos foram realizados em dois cenrios, em relao
implementao
baseada
em
locks.
No
primeiro
cenrio,
no
foram
contabilizados os ciclos
e energia desperdiados devido a espera ocupada. No segundo,
os ciclos e
energia gastos na espera ocupada foram contabilizados, atravs

de penalidades
em ciclos (variando de 1k a 10k ciclos) quando o bloqueio no
pode ser adquirido
prontamente.
Algumas afirmaes podem ser feitas com base nos resultados
obtidos. No
primeiro cenrio, a abordagem utilizando-se de locks superou a
STM em energia
47
e desempenho, em praticamente todas aplicaes. No entanto,
para algumas
aplicaes, a STM mostrou-se competitiva em termos de
energia e desempenho,
em especial para aplicaes com taxas de conflitos baixa. Em
aplicaes com
altas taxas de conflitos, a utilizao de STM foi em mdia 3x
mais ineficiente
em relao aos locks, chegando cerca de 22x em uma aplicao
especfica. No
segundo cenrio, de modo geral, o desempenho da STM
mostrou-se inferior em
relao utilizao de locks, no entanto, a diferena entre o
desempenho de
ambas abordagens poderia ser reduzido quando incorrer
penalidades altas para
o mecanismo de locks. Alm disso, demonstrou-se que para
algumas aplicaes
transacionais, com baixas taxas de conflito, a utilizao de STM
pode se tornar
atraente dependendo dos custos relacionados as penalidades
dos locks. No
entanto, para aplicaes com alta conteno, a utilizao de

locks mostra-se a
melhor abordagem, mesmo que elevadas penalidades sejam
impostas.
4.7 Avaliao de consumo de energia e desempenho de

HTM
em sistemas embarcados multiprocessados
O trabalho de Kunz (2010) avalia o consumo de energia e
desempenho
do modelo LogTM em comparao ao mecanismo de locks, em
um sistema
embarcado multiprocessado. Alm disso, avalia o desempenho
e consumo de
energia de diferentes polticas de gerenciadores de conteno.
A interconexo entre os ncleos de processamento foi baseada
em uma arquitetura
de rede chamada NoC (Network on Chip), sendo esta, uma
alternativa
as interconexes tradicionais como barramentos e chaves
crossbar (BENINI;
DE MICHELI, 2002) (BJERREGAARD; MAHADEVAN, 2006). Uma
NoC uma
estrutura de comunicao formada por diversos roteadores
conectados entre
si de acordo com determinada topologia. Cada roteador
associado a algum
elemento do conjunto da rede (processadores, memrias, entre
outros). As NoCs
permitem elevado grau de paralelismo na comunicao, pois os
links da rede
podem operar de modo simultneo sobre diferentes pacotes de
dados. Apesar
das
solues
tradicionais
(barramentos
crossbar)
apresentarem vantagens em
termos de simplicidade, compatibilidade e latncia, os limites
fsicos impostos
pelo fio, questes relacionadas a escalabilidade e largura de
banda apontam
para a NoC como a melhor alternativa para futuras geraes de
processadores
many-core (BJERREGAARD; MAHADEVAN, 2006).
O sistema computacional utilizado na realizao dos testes
utilizou-se de 2,
4, 8, 16 e 32 processadores, todos operando sobre frequncia
de 100 MHz.
Os tamanhos de cache L1 usadas foram de 512, 1024, 2048 e
8192 bytes,
sendo
essas
completamente
associativas
e baseadas
no
protocolo de coerncia
MSI baseado em diretrio. A configurao da NoC baseada no
roteamento
XY,
chaveamento
Wormhole,
topologia
Grade
(mesh),
arbitragem Round-robin e
frequncia de operao de 100 MHz.
A implementao e os experimentos realizados neste trabalho
foram feitos na
plataforma virtual SIMPLE (BARCELOS; BRIO; WAGNER, 2007).
O consumo
de energia foi obtido levando-se em considerao a energia da
rede, memrias,
caches e processadores do sistema. A energia da NoC foi
calculada atravs da
biblioteca Orion (WANG et al., 2002), enquanto que a energia
das memrias e
das caches foi calculada com a ferramenta Cacti (WILTON;

JOUPPI, 1996).
48
Para os experimentos em aplicaes de baixa conteno, trs
benchmarks
foram utilizados: Multiplicao de Matrizes, Codificador JPEG e
Estimao de
Movimento. Para o cenrio de alta conteno, uma aplicao
que utiliza de alta
demanda de sincronizao durante a maior parte de sua
execuo foi testada,
LeeTM (ANSARI et al., 2008). A aplicao LeeTM possui
paralelismo intrnseco,
no entanto, este paralelismo difcil de expressar utilizando-se
do mecanismo
de locks. Para avaliar o comportamento do sistema para o caso
em que no
h paralelismo disponvel para as transaes, desenvolveu-se
neste trabalho
uma modificao do LeeTM para forar artificialmente a
conteno. Com a
modificao realizada, a quantidade de paralelismo que a TM
pode explorar
a mesma que a verso baseada em locks, o que permite
analisar o overhead
de performance e energia de cada mecanismo (TM e locks) para
o pior caso em
termos de paralelismo desta aplicao. Esta aplicao LeeTM
com inibio do
paralelismo chamada de LeeTM-IP.
Nos
experimentos
conteno, o gerenciador
realizados
para
aplicaes
de
baixa
de conteno da memria transacional utilizada baseou-se na

tcnica de
backoff com valores fixos. O tempo de espera usado foi de 5000
ciclos (para
2,4 e 8 processadores), 10000 ciclos (para 16 processadores) e
25000 (para
32 processadores). Atravs dos resultados obtidos para o
cenrio de baixa
conteno, mostrou-se que na maioria dos casos para at 4
processadores, a
memria transacional apresentou-se ligeiramente inferior em
relao aos locks,
em termos de desempenho. Na utilizao a partir de 6
processadores obtevese
um aumento de performance da memria transacional
medida que o
nmero de processadores aumentava, superando os locks em
todos os casos,
chegando a 30% no melhor caso. Em relao energia
consumida, nas
trs aplicaes e em todas configuraes testadas, a memria
transacional
apresentou-se
eficiente
em
comparao
aos
locks,
apresentando redues de
energia em todos os casos. De maneira geral, os resultados de
energia seguem
os ganhos de performance medida que o nmero de
processadores do sistema
foi aumentado, e, em muitos casos, os ganhos de energia
ultrapassaram os de
desempenho, indicando que a potncia mdia tambm foi
reduzida.
No cenrio de alta conteno, como primeiro experimento, foi

feita uma
anlise para encontrar o valor timo para o tempo de espera de
backoff
(fixo,
exponencial
linear
randmico)
para
diferentes
configuraes do sistema
(nmero de processadores), utilizando-se da aplicao LeeTM.
Para isso,
encontrou-se o parmetro que d o menor tempo de execuo
para cada poltica
de backoff de cada configurao do sistema.
Como alternativa ao encontro da melhor heurstica para ajustar
o tempo de
espera de backoff, os autores propuseram uma nova estratgia
de gerenciamento
de conteno, chamada de Abort Handshake. A soluo
proposta
baseada em sinalizao entre transaes de forma que a
transao abortada
seja notificada quando for seguro reiniciar para evitar que
ocorra o mesmo
conflito. De modo a exemplificar o funcionamento, quando a
transao T1 aborta
aps conflitar com a transao T0, T1 envia uma mensagem
sinalizando seu
aborto T0 e aguarda at receber o sinal de T0 notificando o
momento de
sua re-execuo. T0 ento adiciona T1 em sua lista de
transaes abortadas.
Quando finalizar a execuo, T0 envia o sinal para T1
permitindo que ela reinicie
a execuo. Afim de evitar situaes de deadlock, uma
transao pode esperar
49
apenas por uma transao de maior prioridade. Alm disso,
uma transao
que tenha abortado outra pode se abortada por uma terceira
transao; uma
ir notificar a outra aps o commit e assim sucessivamente.
Esta soluo serializa por completo a execuo de duas
transaes quando
uma delas aborta ao permitir que esta reinicie apenas aps o
commit da outra.
uma soluo conservadora j que a transao que abortou pode
ter trabalho para
executar de forma independente antes de solicitar o bloco
conflitante novamente.
Alm disso, possvel que a transao abortada nem mesmo
solicite o bloco
conflitante novamente se a deciso de requisitar o bloco
depender de dados
alterados por uma terceira transao neste meio tempo.
Em seguida, realizou-se um experimento em ambiente de alta
conteno
comparando as aplicaes LeeTM e LeeTM-IP, utilizando locks,
memria transacional
com o mecanismo Abort Handshake e memria transacional
com
os
valores
timos
para
cada
poltica
de
backoff
(fixo,
exponencial e linear
randmico). Como resultados deste experimento verificou-se
que no houve
vantagens em termos de desempenho e energia na verso das
aplicaes
utilizando locks, para mais de 4 processadores. Nenhuma das
polticas de
backoff pode ser escolhida como vencedora, pois todas tiveram

resultados
parecidos e a melhor depende de cada caso. Em situaes de
alta conteno,
o backoff exponencial aumenta muito o tempo de espera das
transaes,
prejudicando significamente a performance e elevando o
consumo de energia.
O
mecanismo
Abort
Handshake
apresentou
ganhos
de
performance e energia
na maioria dos resultados, atingindo redues do tempo de
execuo em
20% e reduo de energia de 53%, se comparados com a
melhor poltica de
backoff em cada caso. Entretanto, para alguns casos, algumas
peculiaridades
podem afetar o desempenho do Abort Handshake. Embora que,
na utilizao
de 2 processadores o mecanismo Abort Handshake foi inferior
em termos de
energia e desempenho em relao a todas polticas de backoff,
a partir de 4
processadores, na maioria dos casos, o Abort Handshake
apresentou ganhos
significativos de performance e energia. No entanto, observouse que na maioria
dos resultados, reduziu-se drasticamente o desempenho e
elevou-se o consumo
de energia do mecanismo Abort Handshake, em comparao a
locks e a
memria
transacional
processadores. Sendo
com
backoff,
na
utilizao
de
32
ento necessrio, em um estudo futuro, analisar a eficincia do

mecanismo Abort
Handshake utilizando-se mais de 32 processadores.
4.8 Comparao entre implementaes de semforos e

memrias
transacionais em relao ao consumo de energia
O trabalho de Mittal e Nitin (2011) avalia o consumo de energia
e taxa de
cache miss de semforos (spinlock e bloqueante) e memrias
transacionais, na
memria cache compartilhada.
Utilizou-se de uma arquitetura computacional multicore, com 4
cores, cada
um com sua memria privada e duas memrias caches
compartilhadas. A arquitetura
foi simulada com base no conjunto de ferramentas SimpleScalar
(BURGER;
AUSTIN,
1997).
Trs
benchmarks
foram
utilizados
como
aplicaes
bases para os testes: rvores Rubro-Negras, Transformada
Rpida de Fourier e
SPLASH-2 (WOO et al., 1995).
50
De modo geral, os resultados obtidos nos testes realizados
mostraram
que a sincronizao por semforos bloqueantes obteve menos
cache miss em
comparao spinlocks e transaes. Em termos de consumo
de energia,
memrias transacionais e semforos bloqueantes tm um
consumo equivalente,
porm muito eficiente em comparao spinlocks.
Apesar
de
indicar
que
sincronizao
por
semforos
bloqueantes apresenta
melhores taxas de cache miss em comparao spinlocks e
transaes, e
que
em
termos
de
energia
se
equipara
memrias
transacionais, o trabalho
apresenta alguns problemas que tornam seus resultados pouco
convincentes.
No descrito quais aplicaes do benchmark SPLASH-2 foram
utilizadas,
apenas utilizou-se de uma arquitetura computacional (4 cores),
e no foi
explicitado o tipo de memria transacional usada.

Este Captulo apresentou as principais pesquisas que avaliam o
consumo
de energia e/ou desempenho de aplicaes, relacionadas a
mecanismos de
sincronizao em ambiente de memria compartilhada.
Diferentes tcnicas e implementaes de mecanismos de
sincronizao
foram
avaliadas
atravs
dos
oito
trabalhos
descritos
anteriormente. Nesta perspectiva,

as seguintes constataes podem ser feitas, com base nos
resultados
obtidos. Observou-se que o nvel de conteno influencia
consideravelmente o
desempenho e consumo de energia das aplicaes. De modo
geral, altas taxas
de conteno incorrem em custos adicionais em termos de
energia e penalidades
em
desempenho
resoluo de conflito das
nas
memrias
transacionais,
devido
transaes conflitantes e suas re-execues. Para o cenrio de

alta conteno,
as estratgias utilizadas pelo gerenciador de conteno em
transaes garantem
a efetivao de redues de custos adicionais de energia e
penalidades no
desempenho.
No
entanto,
verificou-se
que
no
um
gerenciador de conteno
ideal a ser utilizado em todos os casos. Porm, a escolha ideal
do gerenciador
de conteno varia conforme o nvel de conteno e plataforma
de hardware.
Em
relao
comparao
entre
os
mecanismos
de
sincronizao, as
implementaes
de
STM,
de
modo
geral,
apresentaram
desempenho inferior e
maior consumo de energia se comparadas a utilizao de locks,
em cenrios
de alta conteno. No entanto, em aplicaes com baixo nvel
de conteno,
as
implementaes
de
STM
mostraram-se
competitivas,
superando em desempenho
e eficincia energtica a sincronizao por locks, em muitos
casos. As
implementaes
de
HTM,
por
outro
lado,
mostraram-se
eficientes tanto em
cenrios
de
alta
quanto
baixa
conteno,
superando
eficincia
energtica
abordagem locks em
muitas
vezes
em
termos
de
desempenho, na maioria dos

casos.
5 CONCLUSES E TRABALHOS FUTUROS
Este trabalho apresentou as principais caractersticas da

programao paralela
em ambiente de memria compartilhada, e relacionou-se
mecanismos de
sincronizao
utilizados
para
garantir
integridade
consistncia da comunicao
entre
execues
concorrentes
computao
sustentvel,
especificamente,
visando-se a reduo do consumo de energia em sistemas
computacionais.
Mecanismos
de
sincronizao
em
ambiente
de
memria
compartilhada tm
sido tradicionalmente realizados atravs de mtodos baseados
em bloqueios
(locks)
explcitos
pelo
programador.
No
entanto,
esta
abordagem de sincronizao
propensa a erros, e pode apresentar instabilidade no sistema.
Memrias
Transacionais surgiram como uma alternativa sincronizao
baseada em locks,
visando suprir as dificuldades e limitaes encontradas no uso
de locks. Nas
memrias transacionais, diferentemente da sincronizao por
locks, o controle
sobre a sincronizao feito automaticamente pelo sistema
transacional, o que
facilita a programao, pois o programador apenas precisa
definir quais sero
os
blocos
de
cdigo
serem
executados
pelo
sistema
transacional, e este
implementa a sincronizao em baixo nvel.
A principal contribuio deste trabalho foi analisar diversas
pesquisas que
avaliaram o consumo de energia e/ou desempenho sobre

mecanismos de
sincronizao
em
memria
compartilhada,
focando-se
especialmente em implementaes
de
memrias
transacionais
comparadas
sincronizao
baseada em
locks. Atravs desta anlise constatou-se que a sincronizao
por memrias
transacionais promissora, mostrando-se a melhor abordagem
de sincronizao
em muitos casos. No entanto, verificou-se que a eficincia das
memrias transacionais
varia conforme sua implementao e o cenrio de execuo
(alta e baixa
conteno). As implementaes em hardware mostram-se
eficientes na maioria
dos casos e cenrios, porm, a eficincia do desempenho e
consumo de energia
de memrias transacionais em software (STM) influenciada
diretamente pelo
ambiente de execuo. De modo geral, em cenrios de alta
conteno, as
implementaes em software apresentam desempenho inferior
e maior consumo
de energia se comparadas sincronizao baseada em locks.
Para este tipo
de cenrio, as estratgias de gerenciamento de conteno so
responsveis
por garantir o progresso das transaes conflitantes e por
efetivar redues de
penalidades no desempenho e no consumo de energia. Apesar
de terem se
mostrado inferiores em relao aos locks em cenrios de alta

conteno, as STM
mostram-se competitivas aos locks em aplicaes de baixa
conteno, sendo
superiores em desempenho e eficincia energtica em muitos
casos.
Por se tratar de uma abstrao nova, memrias transacionais
ainda so
52
essencialmente tema de pesquisa, e ainda h muito o que ser
pesquisado para
melhor caracteriz-la.
No encontrou-se na literatura pesquisas que avaliam o
comportamento de
memrias transacionais e outros mecanismos de sincronizao
para ambientes
de memria compartilhada em relao arquiteturas manycore. Tal avaliao
sobre mecanismos de sincronizao seria de suma importncia,
pois este tipo
de arquitetura tendncia para um futuro prximo.
Embora
existam
diversas
estratgias
pesquisas
sobre
gerenciamento de
conteno,
grande
parte
das
pesquisas
avaliam
poucas
estratgias sob um
mesmo contexto, especialmente quando avalia-se o consumo
de energia. Desta
forma, a avaliao de vrias estratgias de gerenciamento de
conteno sob o
mesmo contexto, em termos de consumo de energia e
desempenho, seria de
grande valia, visto que o gerenciador de conteno um
componente essencial
no contexto do sistema transacional.

A maioria das avaliaes de memrias transacionais so
baseadas em
benchmarks ou at mesmo microbenchmarks. Dentre as
pesquisas analisadas
por este trabalho, apenas uma entre as oito avaliou o
comportamento de
memrias transacionais em uma aplicao comercial. Portanto,
a caracterizao
de memrias transacionais em aplicaes no sintticas poderia
ser avaliada em
trabalhos futuros, sendo esta anlise de grande importncia
para o desenvolvimento
efetivo
de
sistemas
comerciais
baseados
em
memrias
transacionais.
53
REFERNCIAS
AMDAHL, G. M. Validity of the single processor approach to
achieving large scale
computing capabilities. In: APRIL 18-20, 1967, SPRING JOINT
COMPUTER
CONFERENCE, 1967, New York, NY, USA. Proceedings. . . ACM,
1967. p.483
485. (AFIPS 67 (Spring)).
ANANIAN, C. S.; ASANOVIC, K.; KUSZMAUL, B. C.; LEISERSON, C.
E.; LIE,
S.
Unbounded
Transactional
Memory.
In:
INTERNATIONAL
SYMPOSIUM ON
HIGH-PERFORMANCE COMPUTER ARCHITECTURE, 11., 2005,
Washington,
DC, USA. Proceedings. . . IEEE Computer Society, 2005. p.316
327.
ANDREWS, G. R. Foundations of multithreaded, parallel, and distributed
programming. Boston: Addison Wesley, 2000.

ANSARI, M.; KOTSELIDIS, C.; WATSON, I.; KIRKHAM, C.; LUJN,
M.;
JARVIS,
K.
Lee-TM:
non-trivial
benchmark
suite
for
transactional memory.
In: IN PROCEEDINGS OF THE 8TH INTERNATIONAL CONFERENCE
ON
ALGORITHMS
AND
ARCHITECTURES
FOR
PARALLEL
PROCESSING,
ICA3PP, 2008. Anais. . . [S.l.: s.n.], 2008.
ARAUJO, A. de; S CAMARGO, C. de; CAVALHEIRO, G.; PILLA, M.
Towards a
power-aware application level scheduler for a multithreaded
runtime environment.
In:
COMPUTER
ARCHITECTURE
AND
HIGH
PERFORMANCE
COMPUTING
WORKSHOPS
(SBAC-PADW),
2010
22ND
INTERNATIONAL
SYMPOSIUM ON,
2010. Anais. . . [S.l.: s.n.], 2010. p.4348.
BALDASSIN, A. J. Explorando Memria Transacional em Software nos
Contextos
de Arquiteturas Assimtricas, Jogos Computacionais e Consumo de
Energia. 2009. Tese (Doutorado em Cincia da Computao)
Universidade
Estadual de Campinas, Campinas, SP, Brasil.
BALDASSIN,
A.;
KLEIN,
F.;
ARAUJO,
G.;
AZEVEDO,
R.;
CENTODUCATTE, P.
Characterizing
the
Energy
Consumption
of
Software
Transactional Memory. IEEE

Comput. Archit. Lett., Washington, DC, USA, v.8, p.5659, July
2009.
BARCELOS, D.; BRIO, E. W.; WAGNER, F. R. A hybrid memory
organization
to enhance task migration and dynamic task allocation in NoCbased MPSoCs.

In: INTEGRATED CIRCUITS AND SYSTEMS DESIGN, 20., 2007,
New York, NY,
USA. Proceedings. . . ACM, 2007. p.282287. (SBCCI 07).
54
BENINI, L.; DE MICHELI, G. Networks on Chips: a new soc
paradigm.
Computer, Los Alamitos, CA, USA, v.35, p.7078, January 2002.
BJERREGAARD, T.; MAHADEVAN, S. A survey of research and
practices of
Network-on-chip. ACM Comput. Surv., New York, NY, USA, v.38,
June 2006.
BLUNDELL, C.; DEVIETTI, J.; LEWIS, E. C.; MARTIN, M. M. K.
Making the
fast
case
common
and
the
uncommon
case
simple
in
unbounded transactional
memory. In: COMPUTER ARCHITECTURE, 34., 2007, New York,
NY, USA.
Proceedings. . . ACM, 2007. p.2434. (ISCA 07).
BURGER, D.; AUSTIN, T. M. The SimpleScalar tool set, version
2.0. SIGARCH
Comput. Archit. News, New York, NY, USA, v.25, p.1325, June
1997.
CAO MINH, C.; CHUNG, J.; KOZYRAKIS, C.; OLUKOTUN, K. STAMP:
stanford
transactional applications for multi-processing. In: IISWC 08:
PROCEEDINGS
OF THE IEEE INTERNATIONAL SYMPOSIUM ON WORKLOAD
CHARACTERIZATION,
2008. Anais. . . [S.l.: s.n.], 2008.
CHUANG, W.; NARAYANASAMY, S.; VENKATESH, G.; SAMPSON, J.;
VAN BIESBROUCK, M.; POKAM, G.; CALDER, B.; COLAVIN, O.

Unbounded
page-based transactional memory. In: ARCHITECTURAL SUPPORT
FOR
PROGRAMMING LANGUAGES AND OPERATING SYSTEMS, 12.,
2006, New
York, NY, USA. Proceedings. . . ACM, 2006. p.347358. (ASPLOSXII).
COFFMAN, E.; ELPHICK, M.; SHOSHANI, A. System deadlocks.
ACM
Computing Surveys (CSUR), [S.l.], v.3, n.2, p.6778, 1971.
DAMRON, P.; FEDOROVA, A.; LEV, Y.; LUCHANGCO, V.; MOIR, M.;
NUSSBAUM,
D.
Hybrid
transactional
memory.
In:
ARCHITECTURAL SUPPORT
FOR PROGRAMMING LANGUAGES AND OPERATING SYSTEMS,
12., 2006,
New York, NY, USA. Proceedings. . . ACM, 2006. p.336346.
(ASPLOS-XII).
DEITEL, H. M.; DEITEL, P. J. Java: como programar. 6.ed. So
Paulo: Pearson
Prentice Hall, 2005.
DICE, D.; SHALEV, O.; SHAVIT, N. Transactional Locking II. In:
INTERNATIONAL
SYMPOSIUM ON DISTRIBUTED COMPUTING (DISC 2006), 20.,
2006.
Proceedings. . . [S.l.: s.n.], 2006. p.194208.
DRAGOJEVIC, A.; GUERRAOUI, R.; KAPALKA, M. Stretching
transactional
memory. In: ACM SIGPLAN CONFERENCE ON PROGRAMMING
LANGUAGE
DESIGN AND IMPLEMENTATION, 2009., 2009, New York, NY, USA.
Proceedings. . . ACM, 2009. p.155165. (PLDI 09).
ENNALS, R. Software Transactional Memory Should Not Be Obstruction-
Free. [S.l.]: Intel Research Cambridge Tech Report, 2006. (IRCTR-06-052).

FELBER, P.; FETZER, C.; RIEGEL, T. Dynamic performance tuning
of wordbased
software transactional memory. In: ACM SIGPLAN SYMPOSIUM
ON
PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING, 13.,
2008, New
York, NY, USA. Proceedings. . . ACM, 2008. p.237246. (PPoPP
08).
55
FLEISCHMANN, M. Quantitative models for reverse logistics: lecture
notes in
economics and mathematical systems. [S.l.]: Springer-Verlag,
Germany, 2001.
FORREST, W.; KAPLAN, J.; KINDLER, N. Data Centers: how to cut
carbon
emissions and costs. McKinsey on Business Technology, [S.l.], v.14,
n.6, 2008.
FRASER, K. Practical lock-freedom. [S.l.]: University of Cambridge,
2004.
(Relatrio Tcnico 579).
GRAY, J.; REUTER, A. Transaction processing: concepts and
techniques. [S.l.]:
Morgan Kaufmann, 1993.
GUERRAOUI,
R.;
HERLIHY,
M.;
POCHON,
B.
Polymorphic
Contention
Management. In: DISC 05: PROCEEDINGS OF THE NINETEENTH
INTERNATIONAL
SYMPOSIUM ON DISTRIBUTED COMPUTING, 2005. Anais. . . LNCS:
Springer, 2005. p.303323.
HAMM, S. Its too darn hot. Businessweek. com, [S.l.], 2008.
HAMMOND, L.; WONG, V.; CHEN, M.; CARLSTROM, B. D.; DAVIS,

J. D.;
HERTZBERG, B.; PRABHU, M. K.; WIJAYA, H.; KOZYRAKIS, C.;
OLUKOTUN,
K.
Transactional
Memory
Coherence
and
Consistency.
In:
COMPUTER
ARCHITECTURE, 31., 2004, Washington, DC, USA. Proceedings. . .
IEEE
Computer Society, 2004. p.102. (ISCA 04).
HARMON, R.; AUSEKLIS, N. Sustainable IT services: assessing
the impact of
green computing practices. In: MANAGEMENT OF ENGINEERING
& TECHNOLOGY,
2009. PICMET 2009. PORTLAND INTERNATIONAL CONFERENCE
ON,
2009. Anais. . . [S.l.: s.n.], 2009. p.17071717.
HARRIS, T.; FRASER, K. Language support for lightweight
transactions.
In:
ACM
SIGPLAN
CONFERENCE
ON
OBJECT-ORIENTED
PROGRAMING,
SYSTEMS, LANGUAGES, AND APPLICATIONS, 18., 2003, New
York, NY, USA.
Proceedings. . . ACM, 2003. p.388402. (OOPSLA 03).
HARRIS, T.; MARLOW, S.; PEYTON-JONES, S.; HERLIHY, M.
Composable
memory
transactions.
In:
ACM
SIGPLAN
SYMPOSIUM
ON
PRINCIPLES AND
PRACTICE OF PARALLEL PROGRAMMING, 2005. Proceedings. . .
[S.l.: s.n.],
2005. p.4860.
HARRIS, T.; PLESKO, M.; SHINNAR, A.; TARDITI, D. Optimizing
memory
transactions. In: ACM SIGPLAN CONFERENCE ON PROGRAMMING

LANGUAGE
DESIGN AND IMPLEMENTATION, 2006., 2006, New York, NY, USA.
Proceedings. . . ACM, 2006. p.1425. (PLDI 06).
HERLIHY, M.; LUCHANGCO, V.; MOIR, M.; SCHERER III, W. N.
Software
transactional memory for dynamic-sized data structures. In:
PRINCIPLES OF
DISTRIBUTED
COMPUTING,
2003,
New
York,
NY,
USA.
Proceedings. . . ACM,
2003. p.92101. (PODC 03).
HERLIHY, M.; MOSS, J. E. B. Transactional memory: architectural
support
for lock-free data structures. In: OF THE 20TH ANNUAL
INTERNATIONAL
56
SYMPOSIUM ON COMPUTER ARCHITECTURE, 1993, New York,
NY, USA.
Proceedings. . . ACM, 1993. p.289300. (ISCA 93).
HOLT, R. C. Some Deadlock Properties of Computer Systems.
ACM Comput.
Surv., New York, NY, USA, v.4, p.179196, September 1972.
JONES,
S.
Beautiful
concurrency.
Beautiful
Code:
Leading
Programmers
Explain How They Think (Theory in Practice (OReilly)). OReilly Media,
Inc,
[S.l.], p.385406, 2007.
KAXIRAS, S.; MARTONOSI, M. Computer Architecture Techniques for
PowerEfficiency. [S.l.]: Morgan & Claypool Publishers, 2008. (Synthesis
Lectures on
Computer Architecture).
KLEIN, F.; BALDASSIN, A.; MOREIRA, J.; CENTODUCATTE, P.; RIGO,
S.; AZEVEDO, R. STM versus lock-based systems: an energy

consumption
perspective. In: ACM/IEEE INTERNATIONAL SYMPOSIUM ON LOW
POWER
ELECTRONICS AND DESIGN, 16., 2010, New York, NY, USA.
Proceedings. . .
ACM, 2010. p.431436. (ISLPED 10).
KRONBAUER, F.; RIGO, S. Experimentos com Gerenciamento de
Conteno em
uma Memria Transacional com Suporte em Software. Anais do X
Simpsio em
Sistemas Computacionais WSCAD-SSC, So Paulo, SP, Brasil, p.44
51, 2009.
KUMAR, S.; CHU, M.; HUGHES, C. J.; KUNDU, P.; NGUYEN, A.
Hybrid
transactional
memory.
In:
ACM
SIGPLAN
SYMPOSIUM
ON
PRINCIPLES
AND PRACTICE OF PARALLEL PROGRAMMING, 2006, New York,
NY, USA.
Proceedings. . . ACM, 2006. p.209220. (PPoPP 06).
KUNZ,
L.
Memria Transacional em Hardware
para
Sistemas
Embarcados
Multiprocessados Conectados por Redes-em-Chip. 2010. Dissertao
(Mestrado em Cincia da Computao) Universidade Federal
do Rio Grande
do Sul, Porto Alegre, RS, Brasil.
KURP, P. Green computing. Commun. ACM, New York, NY, USA,
v.51, p.1113,
Oct. 2008.
LAMB, J. The Greening of IT: how companies can make a
difference for the
environment. 1st.ed. [S.l.]: IBM Press, 2009.
LEVESON, N. G.; TURNER, C. S. An Investigation of the Therac25 Accidents.

Computer, Los Alamitos, CA, USA, v.26, p.1841, July 1993.
LOGHI, M.; PONCINO, M.; BENINI, L. Cycle-accurate power
analysis for
multiprocessor
systems-on-a-chip.
In:
ACM
GREAT
LAKES
SYMPOSIUM ON
VLSI, 14., 2004, New York, NY, USA. Proceedings. . . ACM, 2004.
p.410406.
(GLSVLSI 04).
MAGNUSSON,
P.
S.;
CHRISTENSSON,
M.;
ESKILSON,
J.;
FORSGREN, D.;
HLLBERG, G.; HGBERG, J.; LARSSON, F.; MOESTEDT, A.;
WERNER, B.
Simics: a full system simulation platform.
Computer, Los
Alamitos, CA, USA,

v.35, p.5058, February 2002.
57
MARATHE, V. J.; Scherer III, W. N.; SCOTT, M. L. Adaptive
Software
Transactional Memory. In: INTERNATIONAL SYMPOSIUM ON
DISTRIBUTED
COMPUTING, 19., 2005, Cracow, Poland. Proceedings. . . [S.l.:
s.n.], 2005.
p.354368. Earlier but expanded version available as TR 868,
University of
Rochester Computer Science Dept., May2005.
MARATHE, V. J.; SPEAR, M. F.; HERIOT, C.; ACHARYA, A.;
EISENSTAT, D.;
III, W. N. S.; SCOTT, M. L. Lowering the overhead of nonblocking
software
transactional memory. In: FIRST ACM SIGPLAN WORKSHOP ON
LANGUAGES,
COMPILERS, AND HARDWARE SUPPORT FOR TRANSACTIONAL

COMPUTING, 2006. Anais. . . [S.l.: s.n.], 2006.
MCKENNEY, P. E.; MICHAEL, M. M.; TRIPLETT, J.; WALPOLE, J. Why
the
grass may not be greener on the other side: a comparison of
locking vs.
transactional memory. SIGOPS Oper. Syst. Rev., New York, NY,
USA, v.44, p.93
101, August 2010.
MINH, C. C.; TRAUTMANN, M.; CHUNG, J.; MCDONALD, A.;
BRONSON,
N.; CASPER, J.; KOZYRAKIS, C.; OLUKOTUN, K. An effective hybrid
transactional memory system with strong isolation guarantees.
In: COMPUTER
ARCHITECTURE, 34., 2007, New York, NY, USA. Proceedings. . .
ACM, 2007.
p.6980. (ISCA 07).
MITTAL, S.; NITIN. A Resolution for Shared Memory Conflict in
Multiprocessor
System-on-a-Chip. International Journal of Computer Science Issues,
IJCSI,
[S.l.], v.8, p.503507, July 2011.
MOORE, K. E.; BOBBA, J.; MORAVAN, M. J.; HILL, M. D.; WOOD, D.
A. LogTM:
log-based transactional memory. In: Proceedings of the 12th
International
Symposium on High-Performance Computer Architecture. [S.l.: s.n.],
2006.
p.254265.
MORESHET, T.; BAHAR, R. I.; HERLIHY, M. Energy reduction in
multiprocessor
systems
using
ELECTRONICS AND
transactional
memory.
In:
LOW
POWER
DESIGN, 2005., 2005, New York, NY, USA. Proceedings. . . ACM,

2005. p.331
334. (ISLPED 05).
MORESHET, T.; BAHAR, R. I.; HERLIHY, M. Energy-aware
microprocessor
synchronization: transactional memory vs. locks. In 4th Workshop
on Memory
Performance
Issues,
held
in
conjunction
with
the
International
Symposium
on High-Performance Computer Architecture, [S.l.], 2006.
MR, S. D. K.; ALVES, M. A.; LIMA, J. V. F.; MAILARD, N. B.;
NAVAUX, P. O. A.
Eficincia Energtica em Computao de Alto Desempenho:
uma abordagem
em arquitetura e programao para green computing. XXX
Congresso da
Sociedade Brasileira de Computao, CSBC, [S.l.], p.346360, 2010.
MURUGESAN, S. Harnessing Green IT: principles and practices.
IT Professional,
Piscataway, NJ, USA, v.10, p.2433, January 2008.
OLIVEIRA, R. S. de; CARISSIMI, A. d. S.; TOSCANI, S. S. Sistemas
Operacionais. 3.ed. Porto Alegre: Editora Bookman, 2008.
58
POULSEN, K. Tracking the blackout bug. Security Focus, April,
[S.l.], 2004.
RAJWAR, R.; HERLIHY, M.; LAI, K. Virtualizing Transactional
Memory.
In: COMPUTER ARCHITECTURE, 32., 2005, Washington, DC, USA.
Proceedings. . . IEEE Computer Society, 2005. p.494505. (ISCA
05).
RAMADAN, H. E.; ROSSBACH, C. J.; PORTER, D. E.; HOFMANN, O.
S.;
BHANDARI, A.; WITCHEL, E. MetaTM/TxLinux: transactional

memory for an
operating system. In: COMPUTER ARCHITECTURE, 34., 2007,
New York, NY,
USA. Proceedings. . . ACM, 2007. p.92103. (ISCA 07).
RAMANATHAN, T.; THOMAS, V. Platform 2015: intel processor
and platform
evolution for the next decade. Intel Corporation White Paper, [S.l.],
2005.
RIGO,
S.;
CENTODUCATTE,
P.;
BALDASSIN,
A.
Memrias
Transacionais: uma
nova alternativa para programao concorrente. [S.l.]: In
Proceedings of the
19th International Symposium on Computer Architecture and
High Performance
Computing, 2007.
SAHA, B.; ADL-TABATABAI, A.-R.; JACOBSON, Q. Architectural
Support for
Software
Transactional
Memory.
In:
ANNUAL
IEEE/ACM
INTERNATIONAL
SYMPOSIUM ON MICROARCHITECTURE, 39., 2006, Washington,
DC, USA.
Proceedings. . . IEEE Computer Society, 2006. p.185196. (MICRO
39).
SAHA, B.; ADL-TABATABAI, A. reza; HUDSON, R. L.; MINH, C. C.;
HERTZBERG,
B.
McRT-STM:
high
performance
software
transactional memory
system for a multi-core runtime. In: IN PROC. OF THE 11TH ACM
SYMP. ON
PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING, 2006.
Anais. . .
ACM Press, 2006. p.187197.
SHARAVANAN, S.; POONGODI, D.; KUMAR, A. Towards Green

Computing:
energy
efficient
data
centers.
Journal
of
Mathematics and
Technology, [S.l.],
p.131135, 2010.
SHAVIT, N.; TOUITOU, D. Software transactional memory. In:
ACM SYMPOSIUM
ON PRINCIPLES OF DISTRIBUTED COMPUTING, 1995, New York,
NY, USA.
Proceedings. . . ACM, 1995. p.204213. (PODC 95).
SHRIRAMAN,
A.;
DWARKADAS,
S.;
SCOTT,
M.
L.
Flexible
Decoupled
Transactional Memory Support. In: ANNUAL INTERNATIONAL
SYMPOSIUM
ON COMPUTER ARCHITECTURE, 35., 2008, Washington, DC,
USA.
Proceedings. . . IEEE Computer Society, 2008. p.139150. (ISCA
08).
SHRIRAMAN, A.; SPEAR, M. F.; HOSSAIN, H.; MARATHE, V. J.;
DWARKADAS,
S.; SCOTT, M. L. An integrated hardware-software approach to
flexible
transactional memory. In: COMPUTER ARCHITECTURE, 34., 2007,
New York,
NY, USA. Proceedings. . . ACM, 2007. p.104115. (ISCA 07).
SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. Fundamentos de
Sistemas
Operacionais. 6.ed. Rio de Janeiro: Editora LTC, 2009.
TANENBAUM, A. S.; WOODHULL, A. S. Sistemas Operacionais:
projeto e
implementao. 3.ed. Porto Alegre: Editora Bookman, 2008.
59
UHRIG, S.; UNGERER, T. Energy Management for Embedded

Multithreaded
Processors with Integrated EDF Scheduling. Systems Aspects in
Organic and
Pervasive Computing-ARCS 2005, [S.l.], p.117, 2005.
WANG, H.-S.; ZHU, X.; PEH, L.-S.; MALIK, S. Orion: a powerperformance
simulator
for
interconnection
networks.
In:
ACM/IEEE
INTERNATIONAL
SYMPOSIUM ON MICROARCHITECTURE, 35., 2002, Los Alamitos,
CA, USA.
Proceedings. . . IEEE Computer Society Press, 2002. p.294305.
(MICRO 35).
WECHSLER, O. Setting New Standards for Energy-Efficient
Performance. White
Paper, Inside Intel Core Microarchitecture, [S.l.], p.45, 2006.
WILNER, D. Vx-files: what really happened on mars. In: KEYNOTE
AT THE 18TH
IEEE REAL-TIME SYSTEMS SYMPOSIUM (RTSS97), DEZ, 1997.
Anais. . .
[S.l.: s.n.], 1997.
WILTON, S. J. E.; JOUPPI, N. P. CACTI: an enhanced cache access
and cycle
time model. IEEE Journal of Solid-State Circuits, [S.l.], v.31, p.677
688, 1996.
WOO, S. C.; OHARA, M.; TORRIE, E.; SINGH, J. P.; GUPTA, A. The
SPLASH-2
programs: characterization and methodological considerations.
In: COMPUTER
ARCHITECTURE, 22., 1995, New York, NY, USA. Proceedings. . .
ACM, 1995.
p.2436. (ISCA 95).

PORTIFOLIO Recupera Theards

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PORTIFOLIO Recupera Theards

Încărcat de

Drepturi de autor:

Formate disponibile

1 INTRODUO

O poder computacional est a cada dia mais presente no

multithreaded (ANDREWS, 2000). Neste modelo, o paralelismo

(MCKENNEY et al., 2010): instabilidade no sistema, dificuldade de

programao concorrente, com destaque para o mecanismo de

1.2 Organizao do texto

tpicos sobre comunicao e sincronizao

sincronizao que visam garantir a consistncia e integridade em

2.2 Objetivos e prticas

menor uso de materiais nocivos na fabricao de computadores, e

multicore, a programao paralela tem papel

Uma das caractersticas de processadores multicore est relacionada

de execuo, de acordo com a demanda computacional, obtendo-se

utilizar a memria cache de maneira mais eficiente, pois ocorrem

2.3 Observaes finais

usurios podem estar interessados na mesma informao, por

de mensagens (SILBERSCHATZ; GALVIN; GAGNE, 2009). No modelo

mensagens no decorrer do mesmo.

3.1 Seo Crtica

public class ContaBancaria {

pr ivate double saldo = 0;

public void deposi ta ( double quant ia ) {

this . saldo = this . saldo + quant ia ; / / Seo Cr t i c a

System. out . p r i n t l n ("A quantia do depsito deve ser maior

public void saque ( double quant ia ) {

i f ( this . saldo quant ia > 0) {

this . saldo = this . saldo quant ia ; / / Seo Cr t i c a

System. out . p r i n t l n ("Saldo insuficiente para o valor de

Figura 1: Estrutura de um programa com Seo Crtica

3.2 Problemas de concorrncia

geradas por acessos

instante de tempo as duas threads alocam o mesmo recurso na

liberados explicitamente pelo processo/thread que os possui.

executar at o fim, liberar o recurso R3, e ento o processo P5

Situaes como a do exemplo descrito anteriormente so

3.2.4 Inverso de prioridade

3.3 Primitivas de sincronizao

para postergao ou avano de determinadas tarefas. As

tem-se uma complicao na criao de sistemas confiveis e

sistema. Quanto maior a granularidade do cdigo protegido por

com a garantia de progresso de suas operaes (BALDASSIN,

(BALDASSIN, 2009). Por

somente atravs de duas operaes atmicas padres: wait e

Figura 4: Implementao semforo espera ocupada - instruo

Figura 5: Implementao semforo espera ocupada - instruo

2009). Este tipo de implementao de semforo tambm

instrues, sendo assim, a probabilidade de um processo/thread

Figura 6: Implementao da excluso mtua com semforos.

tambm pode ser

Figura 7: Semforos - precedncias entre tarefas. Fonte:

Figura 8: Mutex - operao lock. Fonte: (OLIVEIRA; CARISSIMI;

Figura 9: Mutex - operao unlock. Fonte: (OLIVEIRA; CARISSIMI;

Figura 10: Excluso mtua com mutex. Fonte: (OLIVEIRA;

Figura 11: Implementao semforo bloqueante - instruo

Figura 12: Implementao semforo bloqueante - instruo

procedimentos para excluso

monitor inserindo variveis de condio, para essas controlarem

operao signal seja

aguardando na fila de espera de condies, conforme ilustrado

public class ContaBancaria {

pr ivate double saldo = 0;

public synchronized void deposi to ( double quant ia ) {

this . saldo = this . saldo + quant ia ;