Escolar Documentos
Profissional Documentos
Cultura Documentos
PORTIFOLIO Recupera Theards
PORTIFOLIO Recupera Theards
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
apresentar
uma
srie
de
complicaes
tais
como
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
11 em programao
concorrente,
os
mostrando
os
problemas
mecanismos
de
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).
fundamental na
melhoria da eficincia, por fazer melhor proveito dos recursos de
hardwares
disponveis e aumentar o desempenho das aplicaes (MR et al.,
2010).
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
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
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).
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
em
ambientes
de
memria
compartilhada
baseado no modelo
multithreaded, portanto no sero discutidos maiores detalhes
sobre troca de
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
3
4
5
6
podem
executar
i f ( quant ia > 0) {
} else {
10
que ZERO.") ;
11
12
13
14
15
16
17
} else {
18
saque desejado.") ;
19
20
21
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.
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
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
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
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.
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).
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
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,
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
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
faa
progresso,
cenrio
denominado
starvation
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
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;
}
mostrado
na
Figura
4,
percebe-se
que
implementao clssica
da instruo wait requer espera em ao (SILBERSCHATZ;
GALVIN; GAGNE,
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 ;
entanto,
implementao
de
semforos
bloqueante
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 ;
Seno
Libera processo / thread do i n c i o da f i l a do mutex
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
liberando
um
processo/thread
da
fila.
Caso
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
sendo
identificado
pela
palavra
synchronized
(DEITEL; DEITEL,
2005), conforme ilustrado pela Figura 15.
1
3
4
i f ( quant ia > 0) {
} else {
que ZERO.") ;
9
10
11
12
13
14
15
} else {
16
saque desejado.") ;
17
18
19
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).
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
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
atomic {
i f ( quant ia > 0) {
} else {
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
ContaBancaria
contaDestino , Double quant ia ) {
2
atomic {
vazio
mtodo
notifyAll
notifica
os
outros
processos/threads que um
elemento foi removido do buffer.
1
2
atomic {
i f ( i t e n s == 0)
retry;
i tens ;
return b u f f e r [ i t e n s ] ;
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();
10
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
atomic {
orElse
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.
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
precisa
restaurar
as
mudanas
efetuadas
na
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
(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.
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
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
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
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
para
acelerar
tarefas
crticas.
Por
exemplo,
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
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,
Captulo anterior.
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.
resultado
deve-se
significativa
frao
de
energia
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
de
Moreshet,
anteriormente. Utilizando
Bahar
Herlihy
(2005),
descrito
foi
utilizado
um
microbenchmark,
com
duas
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
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
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
aumento
de
atualizaes,
desempenho
torna-se
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.
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
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.
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
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
de
conteno
representam
uma
rea
em
locks.
No
primeiro
cenrio,
no
foram
contabilizados os ciclos
e energia desperdiados devido a espera ocupada. No segundo,
os ciclos e
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
experimentos
conteno, o gerenciador
realizados
para
aplicaes
de
baixa
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.
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
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
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.
avaliadas
atravs
dos
oito
trabalhos
descritos
desempenho
nas
memrias
transacionais,
devido
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
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
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
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
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
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
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.;
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-
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.
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
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,
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.
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.
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
using
ELECTRONICS AND
transactional
memory.
In:
LOW
POWER
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.;
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.
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
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).