1 INTRODUÇÃOO poder computacional está a cada dia mais presente no cotidiano. Percebese isso, com o aumento no número de dispositivos móveis, computadores pessoais, e a computação na nuvem, que em muitos casos utiliza-se de grandes data centers. Estima-se que somente os data centers sejam responsáveis 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 computação têm tomado consciência sobre o consumo energético em sistemas computacionais e os impactos causados por esses no meio ambiente, gerando então uma área de pesquisa ainda recente, a Computação Sustentável (Green Computing), que tem por objetivo prover um conjunto de práticas voltadas para a computação de modo que minimize-se o impacto ambiental (KURP, 2008). Em sistemas computacionais, a eficiência energética pode ser obtida através de otimizações tanto de hardware como software, desde o projeto do circuito, passando pelo sistema operacional, compiladores, chegando até o nível de aplicação. Contudo, tem-se como limitante da redução 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 programação paralela tem papel fundamental na melhoria da eficiência, por fazer melhor proveito dos recursos de hardwares disponíveis e aumentar o desempenho das aplicações (MÓRet al., 2010). Um modelo de programação concorrente muito utilizado é o multithreaded (ANDREWS, 2000). Neste modelo, o paralelismo é explicitado por threads, que compartilham a memória por padrão. A comunicação entre threads concorrentes é feita através da escrita e/ou leitura em variáveis compartilhadas e há necessidade de utilizarse de mecanismos de sincronização para garantir a integridade e consistência de execução entre threads concorrentes (ANDREWS, 2000). Os mecanismos de sincronização têm sido tradicionalmente realizados através de métodos baseados em locks explícitos no código fonte dos programas. Embora muito utilizado, esta abordagem é propensa a erros, podendo apresentar uma série de complicações tais como (MCKENNEY et al., 2010): instabilidade no sistema, dificuldade de composição e baixo desempenho se não empregado corretamente. Novas abstrações que facilitem o desenvolvimento de aplicações paralelas são portanto essenciais (BALDASSIN, 2009). 1.1 Objetivos Este trabalho tem como objetivo principal analisar mecanismos de sincronização em ambiente de memória compartilhada sob o contexto da computação sustentável, visando a redução no consumo de energia e/ou maximização do desempenho. Especificamente, temse como objetivos: realizar uma revisão bibliográfica do assunto, apresentando as características (vantagens e problemas) da programação concorrente, com destaque para o mecanismo de memórias transacionais; e realizar um estudo investigativo em pesquisas já concretizadas que comparam o consumo de energia e/ou o desempenho de memórias transacionais com outros mecanismos de sincronização. 1.2 Organização do texto O trabalho que segue está organizado em 5 Capítulos. O Capítulo 2 apresenta a computação sustentável, suas origens e motivações. O Capítulo 3 tem por objetivo descrever os principais tópicos sobre comunicação e sincronização 11 em programação concorrente, os mostrando os problemas e mecanismos de sincronização que visam garantir a consistência e integridade em execuções concorrentes. No Capítulo 4 será apresentado uma análise das pesquisas já desenvolvidas objetivando redução no consumo de energia e/ou desempenho em mecanismos de sincronização em ambiente de memória compartilhada. Por fim, no Capítulo 5 serão apresentadas as conclusões e os trabalhos futuros. COMPUTAÇÃO SUSTENTÁVEL A utilização de sistemas computacionais faz-se cada vez mais presente em atividades das mais diferentes naturezas. Diversas áreas do conhecimento utilizam-se de aplicações 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 utilização de dispositivos móveis e computadores pessoais, que servem, fundamentalmente, como equipamentos para lazer e comunicação. 2.1 Origens Nos últimos anos, a relação entre o consumo energético em sistemas computacionais e os impactos ambientais causados por esses cunharam o termo computação sustentável. Embora a computação sustentável tenha recentemente se popularizado, suas origens conceituais vêm há mais de duas décadas (HARMON; AUSEKLIS, 2009). Em 1991, a Environmental Protection Agency (Agência de Proteção Ambiental) introduziu o programa Green Lights para promover a eficiência energética em iluminação. Em seguida, introduziu-se o programa Energy Star em 1992, o qual estabeleceu especificações de eficiente energética para computadores e monitores (HARMON; AUSEKLIS, 2009). A popularização da computação sustentável deveu-se principalmente ao rápido crescimento de negócios baseados na internet, e os custos de energia para suprir as demandas de infra-estruturas da tecnologia da informação (HARMON;AUSEKLIS, 2009). Apesar de o consumo energético e seus custos associados terem sido o fator impulsor para o surgimento da computação sustentável, foi a partir das alterações climáticas oriundas do aquecimento global que os benefícios gerados pelas práticas da computação sustentável ganharam notoriedade a nível mundial (HARMON; AUSEKLIS, 2009). 2.2 Objetivos e práticas A Computação Sustentável consiste em um somatório de práticas, tais que o principal objetivo é obter uma minimização dos impactos causados por sistemas computacionais no meio ambiente. O meio ambiente beneficia-se da computação sustentável por meio do consumo eficiente de energia, na redução de emissões de gases de efeito estufa, menor uso de materiais nocivos na fabricação de computadores, e através do incentivo na reutilização e reciclagem de componentes de hardwares (MURUGESAN,2008). Tais práticas fomentam melhorias nas atividades de empresas e clientes, efetivando reduções em custos e contribuem com maior preservação do meio ambiente. Em relação aos data centers, pode-se melhorar a eficiência desses utilizandose de equipamentos eficientes em termos energéticos, reduzindo-se a necessidade de refrigeração, utilizando-se de softwares de gerenciamento de 14 energia (MURUGESAN, 2008). Outra prática que pode colaborar significativamente na redução de custos e energia é a Virtualização, pois permite particionar um único sistema computacional em vários outros denominados de máquinas virtuais, reduzindo-se assim a quantidade de máquinas, espaço físico, refrigeração, entre outros elementos necessários para o funcionamento do ambiente computacional (MURUGESAN, 2008). O aumento da eficiência energética é importante em todo contexto computacional, independente de hardwares e softwares utilizados. Com o advento de arquiteturas multicore, a programação paralela tem papel fundamental na melhoria da eficiência, por fazer melhor proveito dos recursos de hardwares disponíveis e aumentar o desempenho das aplicações (MÓR et al., 2010). Uma das características de processadores multicore está relacionada a maior capacidade de processamento utilizando-se de menor frequência de operação. Em tais processadores, para cada 1% de ganho de desempenho há 3% de consumo de energia (RAMANATHAN; THOMAS, 2005). Utilizandose desta relação de maneira inversa, é de se esperar que diminuindo 15% da frequência de operação de um determinando processador, 45% de energia será economizada. O consumo de energia de processadores pode ser obtido através da equação 1 (WECHSLER, 2006). C representa a capacitância comutada, ou seja, a quantidade de energia que pode ser armazenada em um capacitor equivalente. V é a tensão de alimentação, f é a frequência do clock. A capacitância comutada tem um valor fixo para cada circuito, mas a tensão de alimentação e a frequência do clock podem ser reduzidos em certos limites. Observa-se na equação 1 a dependência da tensão (em Volts) em relação à frequência de clock. Power = C _ V 2 _ f (1) Através da técnica conhecida como DVFS (Dynamic Voltage and Frequency Scaling) (KAXIRAS; MARTONOSI, 2008), a voltagem e frequência de operação dos núcleos de execução de processadores podem ser reduzidas em tempo Em arquiteturas multicore e multiprocessadas. 2010). primeiramente. Durante a realização destas operações. UNGERER. um recurso de programação conhecido como Afinidade permite associar threads a um. podendo comprometer o desempenho global do sistema. Este recurso permite 15 . o processador deve interromper suas atividades e aguardar a finalização do ajuste. de acordo com a demanda computacional. ou a um grupo.. Para a realização de tal técnica. a realização destas operações apresenta um custo associado. O objetivo deste recurso é explorar a localidade de referência a dados na memória cache. acarretando em tempo de processamento perdido (UHRIG. e que o ajuste seja realizado de tal forma afim de garantir os requisitos temporais do sistema. 2005). Portanto. a voltagem do processador/core deve ser alterada. somente após esta etapa a frequência pode ser alterada para a desejada. No entanto. obtendo-se assim. para que essa possa suportar a frequência exigida. a redução do consumo de energia em ordem quadrática. deve-se levar em consideração que tais operações não sejam frequentes e assim tomar tempo de processamento. de processadores/cores (ARAUJO et al.de execução. diminuindo sua ociosidade. a utilização da programação paralela é um fator determinante para a busca da eficiência energética. No contexto de arquiteturas multicore e multiprocessadas. como mostrado por Araujo et al (2010). o consumo de potência (MÓR et al.utilizar a memória cache de maneira mais eficiente. utilizando ao máximo o uso de processadores/cores que já estão ativos. ou até mesmo.. pois um thread em específico será sempre executada sobre o mesmo processador/core ou grupo de processadores/cores. Assim. pois ocorrem menos cache miss. A organização e arquiteturas de processadores paralelos podem colaborar ainda mais na redução do consumo energético. aproveita-se a energia que estes . tanto em termos de consumo de energia quanto desempenho. observou-se que a utilização de tais técnicas em conjunto é eficiente. A exploração do recurso de Afinidade pode ser utilizada em conjunto com a técnica de DVFS. Seja através de componentes de hardwares que visam menor consumo de energia (low-power ). 2010). reduzindose assim. através do desligamento seletivo de unidades de processamento que não estejam sendo utilizadas em uma certa porção de tempo. pois utiliza-se dos recursos à disposição de maneira eficiente. Nesta perspectiva. Com a crescente demanda por recursos computacionais. evitando-se desta forma o uso de processadores/cores extras (MÓR et al. Especificamente. que as demandas de processamento e requisitos temporais dos aplicativos sejam atendidas. 2009): _ Compartilhamento de informações: Em sistemas multiusuário. através de técnicas que utilizam eficientemente os recursos de hardwares disponíveis. Diversas práticas provenientes da programação paralela foram mostradas com objetivo de relacionar esta abordagem de programação à computação sustentável. a computação sustentável tem o propósito de otimizar a computação de modo a utilizar o mínimo necessário de recursos naturais. GALVIN.3 Observações finais Este Capítulo apresentou os conceitos relacionados a computação sustentável. mostrou-se que a programação paralela pode reduzir o consumo de energia de sistemas computacionais. 2010).. elevase também o consumo de recursos ambientais. os problemas e resoluções devido a expansão da computação. GAGNE. diversos . Com isso. garantindo ainda. 2. 3 COMUNICAÇÃO E SINCRONIZAÇÃO A execução concorrente em sistemas se torna interessante pelos seguintes aspectos (SILBERSCHATZ.já estão consumindo. _ Modularidade: A construção de sistemas de forma modular. e gravando arquivos em algum tipo de mídia ao mesmo tempo. O aumento na velocidade só é obtido na sub-divisão de tarefas em ambientes com múltiplos elementos de processamento. O sistema deve ser capaz de fornecer um ambiente que permita o acesso concorrente aos recursos compartilhados. Para que haja cooperação entre execuções concorrentes em sistemas. Existem dois modelos comuns de comunicação entre processos ou threads: memória compartilhada e troca . onde cada sub-tarefa será responsável pela execução de uma parte dos dados ou de uma operação específica. _ Comodidade: A execução de diversas tarefas simultâneas se tornou uma prática usual. um arquivo compartilhado. um usuário pode estar editando um texto. há necessidade dessas se comunicarem.usuários podem estar interessados na mesma informação. ouvindo música. deve-se subdividi-la em sub-tarefas. pois cada função pode ser executada por um determinado elemento de processamento. Por exemplo. dividindose as funções em processos ou threads separados. em um sistema multiprocessado se torna vantajoso. _ Processamento mais veloz: Para executar uma tarefa mais rapidamente. por exemplo. A troca de informações entre processos/threads ocorre por meio de leituras e gravações das áreas da memória compartilhada. compartilham a memória por padrão. sendo essas CPUs conectadas através de uma rede de interconexão (SILBERSCHATZ. portanto não serão discutidos maiores detalhes sobre troca de . pois tais sistemas são compostos de várias CPUs 17 contendo áreas de memórias privativas. Esta abordagem é apropriada para sistemas distribuídos. Este trabalho tem como objetivo realizar um estudo sobre mecanismos de sincronização em ambientes de memória compartilhada baseado no modelo multithreaded.de mensagens (SILBERSCHATZ. como por exemplo um buffer ou link de uma rede de conexão. GAGNE. 2009). GALVIN. Threads por sua vez. O meio de comunicação pode ser implementado de várias formas. 2009). processos utilizam-se de chamadas de sistema do tipo mapeamento da memória para obter acesso a regiões da memória utilizadas por outras tarefas. No modelo de troca de mensagens. No modelo de memória compartilhada. GAGNE. GALVIN. a comunicação entre processos é realizada através da troca de informações por intermédio de um canal de comunicação. Mostra-se na Figura 1 um código escrito na linguagem Java que representa a estrutura de um programa que manipula valores de uma conta bancária. na qual diversas threads concorrentemente e utilizar o recurso compartilhado da classe Java. ou seja.1 Seção Crítica Denomina-se Seção Crítica a parte de código de um programa em que a memória ou recurso compartilhado é acessado. WOODHULL. 5 6 public void deposi ta ( double quant ia ) { podem executar . E por fim. serão respectivamente descritos o que denominase de seção crítica de um programa e os problemas que podem ocorrer durante a comunicação entre processos/threads concorrentes.mensagens no decorrer do mesmo. pois é o atributo compartilhado na estrutura do programa. 2008). os trechos de código que manipulam os dados compartilhados onde possam ocasionar condições de corrida (TANENBAUM.4 serão apresentadas as observações finais. Nas duas próximas seções.3 serão descritos os mecanismos de sincronização. Na Seção 3. na Seção 3. 1 2 public class ContaBancaria { 3 4 pr ivate double saldo = 0. 3. As seções críticas do código mostrado são aquelas em que o atributo saldo é manipulado (linhas 8 e 16). / / Seção Cr í t i c a 17 } else { 18 System. saldo + quant ia .7 i f ( quant ia > 0) { 8 this . saldo = this . 11 } 12 } 13 14 public void saque ( double quant ia ) { 15 i f ( this . p r i n t l n ("Saldo insuficiente para o valor de saque desejado. / / Seção Cr í t i c a 9 } else { 10 System. saldo = this . GAGNE. saldo � quant ia . Para que tarefas concorrentes à mesma seção crítica sejam executadas de .") . p r i n t l n ("A quantia do depósito deve ser maior que ZERO. A garantia que duas ou mais tarefas não acessem simultaneamente a mesma seção crítica denomina-se de exclusão mútua.") . 19 } 20 } 21 } Figura 1: Estrutura de um programa com Seção Crítica O problema da seção crítica está em garantir que somente uma tarefa possa 18 estar executando sua seção crítica no mesmo intervalo de tempo. 2009). out . saldo � quant ia > 0) { 16 this . GALVIN. Diversas primitivas que solucionam o problema da seção crítica estabelecem um protocolo onde define-se uma condição para a tarefa entrar na seção crítica e outra operação que sinalize que a tarefa concluiu a execução da seção crítica (SILBERSCHATZ. out . _ Espera limitada: Nenhuma tarefa pode ter seu ingresso na seção crítica postergado indefinidamente.forma eficiente e correta. que serão descritos na subseção 3.2. 3. devem ser satisfeitas quatro condições (TANENBAUM. serão apresentados os problemas mais conhecidos em ambiente de memória compartilhada. . WOODHULL. 2008). tempo. a utilização de mecanismos de sincronização.1 Condição de corrida Se duas ou mais tarefas (threads ou processos) tentam alocar o mesmo recurso ou dado compartilhado ao mesmo inconsistências de dados podem ocorrer (TANENBAUM. A seguir. _ Independência de fatores físicos: A solução não deve depender da velocidade de execução das tarefas ou do número de processadores disponíveis.2 Problemas de concorrência Diversos problemas podem ocorrer durante a comunicação entre processos/ threads concorrentes. 2008): _ Exclusão mútua: Duas ou mais tarefas não podem estar ao mesmo tempo dentro da mesma seção crítica. tem-se como solução para tais. _ Progresso: Nenhuma tarefa executando fora de sua seção crítica pode bloquear outras tarefas.3. 3. WOODHULL. 2008). GALVIN. baseado na estrutura de código mostrado na Figura 1. Podem ocorrer condições de corrida em qualquer sistema onde haver acesso concorrente a um mesmo recurso compartilhado. Demonstra-se através da Figura 2 a ocorrência de condição de corrida em uma aplicação. Figura 2: Acesso concorrente entre threads . Para resguardar-se da condição de corrida precisa-se garantir que somente um processo/thread manipulará o recurso compartilhado por vez. utilizando-se de mecanismos de sincronização (SILBERSCHATZ. pois não alteram o valor do recurso compartilhado. através de um digrama temporal de execução de um programa 19 que manipula valores de uma conta bancária. 2009). Acessos de leitura concorrente a um recurso compartilhado não geram condições de corrida. GAGNE.Denomina-se de condições de corrida as inconsistências geradas por acessos simultâneos a dados ou recursos compartilhados (TANENBAUM.demonstração de condição de corrida Observa-se na Figura 2 que a condição de corrida ocorreu pois no mesmo . WOODHULL. mas ao menos uma das operações seja de escrita no recurso. SHOSHANI. ELPHICK. deadlocks causam bloqueios perpétuos em processos/threads. Ausência de preempção: Os recursos garantidos anteriormente não podem ser retirados à força de um processo/thread. Condição de exclusão mútua: Cada recurso ou está correntemente atribuído a exatamente um processo/thread ou está disponível.instante de tempo as duas threads alocam o mesmo recurso na memória (variável saldo). 3. 1971): 1. Eles devem ser . assim. quatro condições devem ser verdadeiras (COFFMAN. 2008). pois espera-se por um evento (liberação do recurso) que nunca irá acontecer. 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. Dessa forma. Condição de posse e espera: Os processos/threads que correntemente possuem recursos garantidos anteriormente podem solicitar novos recursos.2. 3.2 Deadlock e Livelock Por definição. Para que ocorram deadlocks. o valor da variável alocada será inconsistente. pois uma das atualizações de ambas threads será perdido. desta forma o resultado final será não-determinístico. 2. WOODHULL. foi concedido e é correntemente mantido por esse processo. o processo P5 não está em deadlock. Dois tipos de nós são utilizados nos grafos: processos. pois o processo P2 não está bloqueado.liberados explicitamente pelo processo/thread que os possui. cada um dos quais esperando por um recurso mantido pelo próximo membro do encadeamento. mantido pelo processo P1. 1972). P3 e P4 estão em deadlock. Condição de espera circular: Deve haver um encadeamento circular de dois ou mais processos/threads. mostrados como quadrados. 20 4. Um arco de um nó de processo (círculo) para um nó de recurso (quadrado) significa que o processo está bloqueado. Os processos P1 e P3 estão bloqueados à espera do recurso R1. Um arco de um nó de recurso para um nó de processo significa que o recurso foi solicitado anteriormente. podendo esse . Desta forma. mantido pelo processo P4. As quatro condições descritas anteriormente podem ser modeladas usando grafos dirigidos (HOLT. Entretanto. esperando por esse recurso. o processo P5 está bloqueado à espera do recurso R3. Na Figura 3(b). mostrados como círculos. O processo P4 está bloqueado à espera do recurso R2. e recursos. P1. A Figura 3(a) mostra graficamente uma situação de deadlock. Um exemplo de uma situação que ocorre livelock é quando duas pessoas caminhando em um corredor estreito em direções opostas se encontram frente a frente. 2000). TOSCANI. for eliminada pelo menos uma das quatro condições descritas acima (TANENBAUM. 2008) Há várias formas de eliminação de deadlocks em sistemas. 2008). porém. Figura 3: Cenários de alocações de recursos compartilhados com ocorrência de deadlock. CARISSIMI. Fonte: (OLIVEIRA. com a diferença que os estados dos processos/threads em livelock não ficam bloqueados. . Livelock é semelhante à deadlock. para cada recurso. A detecção pode ser realizada de forma automática ou manual. não conseguindo progressão. mas permanecem em estado de espera-ocupada (ANDREWS. Ambas tentam seguir caminho em frente. Uma outra forma usual para o tratamento de deadlocks é deixar acontecer. Uma delas é se. detectá-lo e então eliminálo (TANENBAUM. liberar o recurso R3. 2008). O deadlock é eliminado por meio da destruição dos processos/threads envolvidos e da liberação dos respectivos recursos. pois moveram-se para o mesmo lado ao mesmo tempo. cada uma se move para o mesmo lado.executar até o fim. WOODHULL. e então o processo P5 poderá executar. WOODHULL. 2008). eventualmente. 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. GAGNE. ou inanição.3 Starvation Starvation. GAGNE. porém. 2000). GALVIN.Situações como a do exemplo descrito anteriormente são comuns de acontecer em certos ambientes. 2009). o progresso acontece (ANDREWS.2. TOSCANI. na qual incrementa-se gradualmente a prioridade dos processos/threads que aguardam em filas por longo tempo para executarem (SILBERSCHATZ. refere-se ao tempo indefinido que processos/threads aptos a execução aguardam para executar. CARISSIMI. GALVIN. Uma solução que resolve o problema da inanição em algoritmos de escalonamento por prioridades é a técnica conhecida como envelhecimento. . 21 3. Tal situação pode ocorrer em algoritmos de escalonamento por prioridades. na qual algum processo/thread em específico pode sempre perder na disputa pela entrada na seção crítica (OLIVEIRA. Outra situação em que a inanição pode ocorrer é em sincronização por espera-ocupada. 2009). Somente após o processo/thread de baixa prioridade concluir a execução da seção crítica a tarefa de alta prioridade poderá prosseguir.2. 2000). A exclusão mútua garante que não haverá acesso simultâneo em uma região de memória compartilhada. ou a condição . Mecanismos de sincronização têm sido tradicionalmente implementados com uso de bloqueios (locks) explícitos pelo programador. Duas formas de sincronização se fazem necessárias em aplicações concorrentes: condicional e exclusão mútua (ANDREWS. 2009). GAGNE. 3. onde certas variáveis representam a proteção (entrada e saída) da seção crítica.4 Inversão de prioridade Denomina-se de inversão de prioridade situações em que processos/threads de alta prioridade são impedidos de executar suas seções críticas por essas já estarem sendo executadas por processos/threads de mais baixa prioridade (SILBERSCHATZ. A sincronização condicional permite postergar a execução de um processo ou thread até que alguma condição se satisfaça. controlando a ordem de execução das operações entre diferentes tarefas.3.3 Primitivas de sincronização O objetivo de mecanismos de sincronização é garantir a integridade e consistência em execuções concorrentes. GALVIN. apesar de ser muito utilizado. adquirir locks na ordem errada. Tais situações podem acarretar em: diminuição do paralelismo. 2007) (MCKENNEY et al. torna-se comum algumas situações acontecerem: a utilização de locks em excesso. se não for. adquirir locks errados. como consequência. o processo/thread executará um laço fechado até que seja permitido entrar. Na espera-ocupada o processo/thread verifica se a entrada é permitida na seção crítica. adquirir menos locks do que o necessário. No entanto. WOODHULL.para postergação ou avanço de determinadas tarefas. condições de corrida e deadlocks. Existem basicamente duas classificações: bloqueantes e espera-ocupada (TANENBAUM.. A característica bloqueante refere-se à retirar do escalonamento (suspender) os processos/threads quando esses não podem entrar em suas seções críticas até que alguma condição se satisfaça. 2008). . 2010): 22 _ Instabilidade: como o controle sobre a forma de sincronização é dada através de locks explicitados pelo programador. Por essas razões. este modelo de programação apresenta uma série de problemas (JONES. As implementações de locks podem ser classificadas conforme sua característica. No entanto. não pode ser percebida a ausência do item em uma fila antes que o mesmo seja inserido em outra). sendo requerido atomicidade na execução (ou seja. uma operação que deva mover um item entre duas filas poderia ser composta através de métodos de remoção e inserção. _ Gargalo o serial: fator desempenho está relacionado diretamente à característica conservativa dos bloqueios. através do uso de bloqueios torna-se complicado tal composição sem que o encapsulamento do objeto seja violado ou ainda que novos bloqueios sejam introduzidos. apenas um processo/thread pode acessar por vez. esse processo/thread ficará bloqueado até o recurso ser liberado. Quando um processo/thread tentar acessar uma região de código protegida que já está sendo acessada. continuem válidos. quando combinados. _ Composição: não há garantia em que trechos de código corretamente implementados utilizando bloqueios. causando gargalos seriais no . Por exemplo.tem-se uma complicação na criação de sistemas confiáveis e escaláveis baseados em locks. Em seções críticas protegidas por bloqueios o acesso é restringido. independente do número de processadores utilizados.sistema. S(p) = 1 fs + 1�fs p (2) Mesmo para um número de processadores que tende ao infinto. Desta forma. A equação descreve o speedup máximo S(p) obtido com p processadores em um programa cuja fração de tempo de execução serial é dada por fs. o speedup é limitado pela fração de código serial presente em um programa. o speedup máximo obtido será 2. a qual relaciona o acréscimo de desempenho esperado em um algoritmo que possui parcelas sequenciais e paralelas. A análise de tal impacto pode ser obtida utilizando-se da lei de Amdahl (AMDAHL. Quanto maior a granularidade do código protegido por um bloqueio. em uma aplicação cuja 50% do tempo de execução seja estritamente sequencial. dada pela equação 2. maior será o impacto negativo no desempenho e na escalabilidade da aplicação. lim p!1 S(p) = 1 . 1967). de acordo com a equação 3. de acordo . 2010). Embora apresente uma série de desvantagens.. São classificados em três níveis os algoritmos não-bloqueantes. o mecanismo de locks tem como vantagens possibilitar uma programação intuitiva e fácil de usar em muitos casos. além de existir um grande grupo de desenvolvedores experientes que utilizam o mecanismo (MCKENNEY et al. que tem por objetivo resolver os problemas intrínsecos dos locks no acesso à recursos compartilhados (ANDREWS.fs (3) Com base nas equações descritas anteriormente. 2009). evidencia-se que a granularidade da sincronização e a fração serial do código de um programa 23 são fatores determinantes no desenvolvimento de algoritmos concorrentes eficientes. A implementação nãobloqueante exclui qualquer uso de locks. já que esses podem induzir estado de espera (BALDASSIN. Uma alternativa à sincronização baseada em locks é a sincronização nãobloqueante. e diversas plataforma de hardwares existentes oferecerem suporte ao mecanismo. o que evidencia o grande número de softwares que fazem uso deste modelo. 2000). a livre de obstrução não garante progresso em condições em que haja threads concorrentes e conflitantes. Nesse esquema é possível que threads invalidem uma o trabalho da outra sem haver progresso algum. a sincronização livre de espera garante progresso incondicional (BALDASSIN. Livre de obstrução (obstruction-free): Alguma operação sempre termina em um número finito de passos quando livre da interferência de outras operações. .com a garantia de progresso de suas operações (BALDASSIN. quando executada de forma isolada. Já a livre de trava admite que determinada thread não faça progresso. 3. Livre de espera (wait-free): Todas as operações terminam após um número finito de passos. O sistema como um todo faz progresso. cenário denominado starvation (BALDASSIN. Há pelo menos uma thread fazendo progresso. implementar e verificar a corretude dos algoritmos (BALDASSIN. sempre faz progresso. 2. 2009): 1. 2009). 2009). como forma mais fraca. 2009). Livre de trava (lock-free): Alguma operação termina após um número finito de passos. Por fim. Dessa forma. situação conhecida como livelock (BALDASSIN. O grande problema com a sincronização não-bloqueante é a extrema dificuldade em projetar. Uma thread. 2009). Problemas decorrentes de condição de corrida contribuíram para um dos maiores blecautes da história norte-americana em agosto de 2003. falhas sucessivas de operação do dispositivo da missão Pathfinder em Marte foram atribuídas a um problema de inversão de prioridade no software (WILNER. 24 3. afetando cerca de 50 milhões de pessoas (POULSEN. Entre 1985 e 1987. 2008).3. Alguns casos reais ressaltam a dificuldade de desenvolvimento de sistemas concorrentes. será apresentado o mecanismo de Memórias Transacionais. 2004). na qual a característica bloqueante ou não-bloqueante depende de sua implementação. WOODHULL. à parte a inicialização. 1997).3. baseados em locks. Na subseção 3. Nas próximas 3 subseções serão descritos diferentes métodos de sincronização. Dijkstra em 1965 (TANENBAUM. 1993). é acessada .3. Em 1997. Um semáforo S é uma variável inteira que. W.1 Semáforos Semáforo é um mecanismo de sincronização criado pelo matemático holandês E. uma condição de corrida existente no software para o equipamento de radiação médico Therac-25 causou pelo menos seis mortes (LEVESON. TURNER. GAGNE.somente através de duas operações atômicas padrões: wait e signal. GALVIN. 2009). 2009) s i g n a l (S) { S++. GALVIN. percebe-se que a implementação clássica da instrução wait requer espera em ação (SILBERSCHATZ. wai t (S) { whi le (S <= 0) . GALVIN. significando incrementar) (SILBERSCHATZ. GALVIN. As modificações do valor inteiro do semáforo sobre tais operações e o conjunto de instruções no escopo dessas. afim de evitar-se condições de corrida (SILBERSCHATZ. Estas operações eram originalmente designadas como P (da palavra holandesa proberen. que significa testar) e V (da palavra holandesa verhogen.instrução signal. 2009) Conforme mostrado na Figura 4. 2009). .instrução wait. GAGNE. / / nenhuma operação S��. Fonte: (SILBERSCHATZ. GAGNE. GALVIN. Fonte: (SILBERSCHATZ. devem ser executadas de modo indivisível. } Figura 5: Implementação semáforo espera ocupada . Nas Figuras 4 e 5 mostram-se respectivamente as definições clássicas das operações wait e signal. } Figura 4: Implementação semáforo espera ocupada . GAGNE. GAGNE. Em situações onde diversas tarefas aguardam simultaneamente e testam continuamente o valor de lock até este indicar a liberação da seção crítica. depende de qual fluxo de execução consegue adquirir o lock primeiro. Este tipo de implementação de semáforo é também chamado de Spinlock.2009). enquanto aguarda a seção crítica tornar-se liberada (TANENBAUM. e tem como característica. ou espera ocupada. 2008). pois não há estabelecido critérios para ordem de execução da seção crítica. poderá acontecer de 25 algum processo/thread nunca conseguir entrar em sua seção crítica. para qualquer processo/thread que necessitar acessar a seção crítica. e sim. o processo/thread irá testar repetidamente a variável (valor do semáforo) que controla a entrada na seção crítica até essa indicar que a seção está liberada. Spinlock é muito utilizado em situações nas quais a seção crítica contém poucas . pois o processador estará executando o teste continuamente na variável que representa o lock. Isso torna-se uma desvantagem do mecanismo Spinlock. e está já estiver sendo executada por outro fluxo de execução. WOODHULL. O teste de uma variável continuamente até que uma condição se satisfaça denomina-se busy-waiting. o processo/thread será bloqueado. se não for. pode-se modificar a definição das operações de semáforo wait e signal. o processo/thread antes de acessar a seção crítica verifica se é permitido entrar. Ambas implementações de semáforo (Spinlock e bloqueante) resolvem o problema da seção crítica através da implementação da exclusão mútua. Seção c r í t i c a . GALVIN. Para superar a necessidade da espera em ação. um processo/thread da fila associada ao semáforo será retirado para entrar em execução. é verificado se existem processos/threads na fila de espera. GAGNE. conforme ilustrado pela Figura 6. s i g n a l (mutex ) . Nesta implementação. 2009). sendo assim. . Seção remanescente . a probabilidade de um processo/thread encontrar a seção crítica bloqueada é muito baixa.instruções. se existirem. Após um processo/thread concluir a execução de sua seção crítica. reduzindo-se então o desperdício de CPU e a postergação indefinida. o processo/thread deve ser bloqueado. A operação de bloqueio coloca o processo/thread em uma fila de espera associada ao semáforo e o estado do processo/thread é comutado para estado em espera (SILBERSCHATZ. wai t (mutex ) . denominada de bloqueante. Em vez do processo/thread esperar em ação. GALVIN. conhecidas como semáforo binário/mutex. A implementação bloqueante pode variar conforme a implementação das operações wait e signal do semáforo. GALVIN. GAGNE. o valor do semáforo pode assumir apenas dois valores. GAGNE. P2 executará somente após P1 ter invocado signal(synch) o que é feito após o comando S1. a implementação de semáforos bloqueante também pode ser usada para estabelecer relações de precedências entre processos/threads (SILBERSCHATZ. Por exemplo. Duas classificações são comumente empregadas. inicializado em 0. No mutex. um cenário onde dois processos operam concorrentemente: P1 com um comando S1 e P2 com um comando S2. 2009). As operações wait e signal são normalmente chamadas de lock e 26 Processo P1 : . 0 e 1 (livre e ocupado). e semáforo de contagem. Suponha-se que o comando S2 deva ser executado somente depois que S1 concluir sua execução. Como synch é inicializado em 0. Pode-se implementar este esquema deixando que P1 e P2 compartilhem um semáforo comum synch. conforme ilustrado pela Figura 7.Figura 6: Implementação da exclusão mútua com semáforos. 2009) No entanto. Fonte: (SILBERSCHATZ. Unlock (mutex ) : Se f i l a mutex está vazia Então marca mutex como l i v r e . Fonte: (SILBERSCHATZ.operação lock.precedências entre tarefas. A instrução lock verifica se o mutex está livre. CARISSIMI. TOSCANI. Processo P2 : wai t ( synch ) . o fluxo em execução pode entrar na seção crítica. conforme ilustrado pela Figura 8. s i g n a l ( synch ) . Em casos de o mutex estar ocupado o processo/thread é inserido na fila. deve-se marcar a variável mutex como livre.S1 . Figura 7: Semáforos . 2008) A instrução unlock verifica se o mutex contém registros na fila de processos/ threads. 2009) unlock. Fonte: (OLIVEIRA. GALVIN. deve-se liberar um processo/thread da fila para execução da seção crítica. GAGNE. conforme ilustrado na Figura 9. se a fila estiver vazia. S2 . Lock (mutex ) : Se mutex está l i v r e Então marca mutex como ocupado Senão Insere processo / thread no f im da f i l a do mutex Figura 8: Mutex . Quando um processo ou thread precisar acessar uma seção crítica ele deverá chamar o comando lock do mutex. Se a fila não estiver vazia. se estiver. . 2008) Após a saída da seção crítica de um processo/thread. / _ Saída da seção c r í t i c a _ / Figura 10: Exclusão mútua com mutex. Lock (mu) . este deverá chamar a instrução unlock do mutex. / _ Entrada da seção c r í t i c a _ / Seção c r í t i c a . f i l a . o valor deste deverá ser decrementado. GALVIN. GAGNE. CARISSIMI. Unlock (mu) . v a l o r = S. Fonte: (OLIVEIRA. TOSCANI. Se S. 27 Mutex mu = L i v r e .. o processo/thread será bloqueado e inserido na fila desse semáforo. . va l o r < 0 Então Bloqueia processo / thread e insere em S. Fonte: (OLIVEIRA. No semáforo de contagem. Deste modo. 2009). wai t (S) : S.Senão Libera processo / thread do i n í c i o da f i l a do mutex Figura 9: Mutex . 2008) Ao ser executada a instrução wait sobre um semáforo de contagem. aceita-se valores negativos para o valor do semáforo. Caso o novo valor do semáforo seja negativo. CARISSIMI.operação unlock. TOSCANI. se o valor for negativo. sua magnitude será igual ao número de processos/threads em espera na fila daquele semáforo (SILBERSCHATZ. conforme ilustrado pela Figura 10. . va l o r � 1. f i l a não está vazia Então Ret i ra processo / thread da f i l a e executa�o . o primeiro elemento da fila deverá ser retirado e executado. Outro problema. v a l o r = S. 2009) A implementação de semáforos com fila de espera pode resultar em situação 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.Figura 11: Implementação semáforo bloqueante . causando uma situação de inanição (SILBERSCHATZ. GALVIN. Se S. GAGNE. 2009). Fonte: (SILBERSCHATZ. 2009) A instrução signal deverá incrementar o valor do semáforo. GAGNE. va l o r + 1. Caso haja algum processo/thread na fila. GALVIN. deve-se adotar políticas de ordenação de filas que evitem tais situações. GALVIN. . Figura 12: Implementação semáforo bloqueante . Fonte: (SILBERSCHATZ. 2009). está relacionado à espera por tempo indefinido de processos/threads em filas. GALVIN. Desta forma. GAGNE. s i g n a l (S) : S. O bloqueio indefinido pode ocorrer se a fila de espera do semáforo for organizada em ordem LIFO (Last In First Out) ou através de escalonamento por prioridades. GAGNE.instrução signal.instrução wait. 2008). A. garantindo a propriedade de exclusão mútua (SILBERSCHATZ. R. É de responsabilidade do compilador implementar a exclusão mútua em entradas de monitor. Embora a implementação de monitores garanta uma maneira simples de obter a exclusão mútua.28 3. e cabe ao compilador preparar os procedimentos para exclusão mútua (TANENBAUM. se houver necessidade de que certas sequências de eventos ocorram ou não. O programador apenas descreve quais serão os procedimentos que farão parte do monitor. deve-se modificar o procedimento vinculado a um . Figura 13: Visão esquemática de um monitor O monitor é uma abstração de alto nível pois é implementado pela linguagem de programação. Hoare em 1974 (TANENBAUM.2 Monitor Monitor é uma primitiva de sincronização de alto nível. 2009). proposto por C. conforme ilustrado na Figura 13.3. e uma maneira comum é utilizar semáforos ou mutex. agrupadas em um tipo especial de módulo ou pacote. desta forma. A estrutura do tipo monitor define que somente um processo/thread por vez possa estar ativo dentro do monitor. 2008). WOODHULL. GALVIN. variáveis e estruturas de dados. WOODHULL. GAGNE. Um monitor é um conjunto de procedimentos. WOODHULL. 2008). aguardando a sinalização de diversas condições. Caso a operação signal seja invocada e não haja nenhum processo/thread aguardando a condição. Um processo/thread pode executar um procedimento de um monitor mesmo quando haja um ou mais processos/threads . liberando um processo/thread da fila. As variáveis de condições são manipuladas por intermédio de duas operações. até que algum outro processo/thread sinalize com a operação signal que a condição de espera foi satisfeita. o monitor organiza os processos/threads suspensos em filas associadas às respectivas condições. nenhum efeito surtirá. baseandose em algoritmos de escalonamento.monitor inserindo variáveis de condição. conhecidas como wait e signal. A execução da instrução signal referente a uma condição libera apenas um 29 único processo/thread da fila de espera da condição associada. para essas controlarem a ordem de execução dos eventos (TANENBAUM. É possível que vários processos/threads permaneçam em estado de espera. A operação wait faz com que o processo/thread seja colocado em estado de espera na fila da condição associada. Para isso. 3 4 public synchronized void deposi to ( double quant ia ) { 5 i f ( quant ia > 0) { 6 this .3 Memórias transacionais O termo memória transacional foi cunhado em 1993 por Herlihy e Moss para designar: "uma nova arquitetura para microprocessadores que objetiva tornar . 9 } 10 } 11 12 public synchronized void saque ( double quant ia ) { 13 i f ( this .aguardando na fila de espera de condições. p r i n t l n ("Saldo insuficiente para o valor de saque desejado. sendo identificado pela palavra synchronized (DEITEL. DEITEL. out . conforme ilustrado pela Figura 15. saldo + quant ia . Figura 14: Monitor com variáveis de condição Um exemplo de utilização de monitores na programação pode ser dado através da linguagem Java. out .") . conforme ilustrado pela Figura 14 . 2005).3. 17 } 18 } 19 } Figura 15: Exemplo de código em Java utilizando monitor 3.") . saldo � quant ia > 0) { 14 this . saldo = this . 7 } else { 8 System. saldo = this . onde nessa linguagem todo objeto possui um monitor associado. 15 } else { 16 System. 1 public class ContaBancaria { 2 pr ivate double saldo = 0. p r i n t l n ("A quantia do depósito deve ser maior que ZERO. saldo � quant ia . e os valores pertencentes à execução da transação serão descartados. Quando a transação for efetivada com sucesso o resultado da execução é permanente. A propriedade de atomicidade define que as instruções pertencentes ao escopo da transação serão todas efetivadas com sucesso ou todas descartadas. Quando ocorrer falha na transação. uma transação é uma sequência finita de instruções. diz-se que essa sofreu abort. Este termo define qualquer mecanismo de sincronização que utilize o conceito de transação para coordenar acessos à memória compartilhada. e diz-se que a transação sofreu commit. REUTER. criada e desenvolvida no contexto de sistemas de banco de dados (GRAY. A propriedade de consistência assegura a integridade dos dados.a sincronização livre de bloqueio tão eficiente (e fácil de usar) quanto técnicas 30 convencionais baseadas em exclusão mútua" (HERLIHY. sendo serializadas por uma thread. . A memória transacional usa como principal abstração o conceito de transação. satisfazendo as propriedades ACID (Atomicidade. MOSS. garantindo que uma transação levará o sistema de um estado consistente (prétransação) a outro estado consistente (pós-transação). Nesse domínio. 1993). 1993). Consistência. Isolamento e Durabilidade). O conceito de transação no contexto de memórias transacionais é basicamente o mesmo. O conceito de durabilidade pode ser ignorado em memórias transacionais. Em relação ao uso de bloqueios. 2010): _ Facilidade de programação: a programação torna-se mais fácil porque o programador não tem responsabilidade em como garantir a sincronização. ao contrário de sistemas de banco de dados onde os dados são armazenados em memória persistente. e sim em especificar quais blocos de código devem ser executados atomicamente. implementação do cabendo ao sistema transacional a .. A propriedade de durabilidade indica que as mudanças efetivadas por transações são permanentes e resistentes a eventuais falhas no sistema. de modo que o resultado de execução de diversas transações seja equivalente ao resultado de execução dessas mesmas em ordem serial. com exceção para a propriedade de durabilidade. pois em seu contexto os dados serão armazenados em memória volátil. a memória transacional apresenta as seguintes vantagens (MCKENNEY et al.O isolamento significa que transações concorrentes não poderão verificar resultados intermediários produzidos por outras transações. 3. em relação à linguagem e semântica. _ Composabilidade: Transações suportam naturalmente a composição de código. _ Escalabilidade: Transações que acessem um mesmo dado para leitura podem ser executadas concorrentemente. as seguintes três construções são . 3.3.mecanismo de sincronização.1 Linguagem e semântica Aspectos referentes à linguagem e semântica são importantes por indicarem o grau de expressividade da linguagem e definir univocamente o significado de cada uma de suas construções (BALDASSIN. O sistema transacional irá garantir que tais operações sejam executadas de forma atômica. deve-se invocá-las dentro de uma nova transação. será apresentado a memória transacional sob a perspectiva do programador. No contexto de memórias transacionais. 31 A seguir. Para criar uma nova operação baseando-se em outras já existentes. Essa característica tem como vantagem garantir que mais desempenho seja obtido com o aumento do número de processadores porque o nível de paralelismo exposto é maior. Também podem ser executadas de modo paralelo as transações que modifiquem partes distintas de uma mesma estrutura de dados. 2009). o qual é responsável por delimitar o escopo que deve ser executado por uma transação (HARRIS. saldo = this . O sistema transacional será responsável por garantir a sincronização do bloco. diferentemente de outras construções como locks. saldo + quant ia . Uma grande vantagem do bloco atômico é que não é necessário criar manualmente variáveis específicas para controlar e bloquear a seção crítica de um programa.atualmente aceitas: atomic. sendo delimitado pela palavra atomic (linha 2 até linha 8). 7 } 8 } 9 } Figura 16: Bloco atômico A composição de transações é ilustrada na Figura 17. out . Na Figura 16 mostra-se um exemplo de implementação do bloco atômico. FRASER. 1 public void deposi ta ( double quant ia ) { 2 atomic { 3 i f ( quant ia > 0) { 4 this . Pelo fato da operação ser . / / Seção Cr í t i c a 5 } else { 6 System.") . p r i n t l n ("A quantia do depósito deve ser maior que ZERO. 2003). Construção atomic A construção atomic representa o bloco atômico. retry e orElse. deixando a encargo do programador apenas especificar quais serão os blocos atômicos e não em como sincronizá-los. através de um método que transfere um valor entre duas contas bancárias. ContaBancaria contaDestino . fazendo com que a transação seja cancelada e re-executada quando a variável itens for modificada por outro processo/thread. 32 1 public void t r a n s f e r e n c i a ( ContaBancaria contaOrigem .efetuada de forma atômica e em isolamento. Quando algum dado compartilhado recentemente acessado pela transação é modificado. a transação é re-executada. suponha-se a remoção de elemento de um buffer. descartando as alterações em ambas operações. . deposi to ( quant ia ) . Por exemplo. desfazendo todas as ações intermediárias (HARRIS et al. Construção retry A construção retry define que a transação seja cancelada. é garantido que nenhuma outra transação verá o estado intermediário na qual o valor sacado de uma conta (linha 3) ainda não tenha sido depositado na outra (linha 4). 4 contaDest ino . 2005). Caso haja falha em alguma das operações (saque ou deposito) o sistema transacional abortará toda transação. Double quant ia ) { 2 atomic { 3 contaOrigem . saque ( quant ia ) . 5 } 6 } Figura 17: Composição em memória transacional Sempre que um buffer estiver vazio a transação invoca a construção retry.. CENTODUCATTE. 2007) 1 2 public synchronized int remover ( ) { 3 int resul tado . quando o método for qualificado como synchronized. Fonte: (RIGO. o mesmo exemplo de remoção de elemento de um buffer será implementado em Java utilizando de monitores. BALDASSIN. O método wait serve para garantir que não seja removido um elemento de um buffer vazio e o método notifyAll notifica os outros processos/threads que um elemento foi removido do buffer. antes de prosseguir com a operação de remoção. A aquisição e liberação de bloqueios é implícita em Java. .Afim de comparar uma construção transacional com outra abordagem de programação. 8 } 9 } Figura 18: Remoção elemento de buffer codificada com a construção retry. conforme mostra na Figura 19. O uso da primitiva synchronized indica que o processo/thread que invocar o método remover deverá obter o bloqueio associado ao objeto buffer. 6 i tens ��. 1 2 public int remover ( ) { 3 atomic { 4 i f ( i t e n s == 0) 5 retry. 7 return b u f f e r [ i t e n s ] . 4 while ( i t e n s == 0) 5 wai t ( ) . 10 } Figura 19: Remoção elemento de buffer codificada em Java com monitor. baixo desempenho. Por exemplo. qualquer outro método do objeto que eventualmente seja invocado será bloqueado até que o método libere o bloqueio. respectivamente. Como um bloqueio associado ao objeto buffer é adquirido ao invocar o método remover. 2007) 33 A partir dos dois exemplos mostrados nas Figuras 18 e 19. Fonte: (RIGO. pois a detecção de conflitos é feita de forma dinâmica (em tempo de execução). Portanto o uso de transações consegue explorar mais paralelismo. Construção orElse A construção orElse permite que transações sejam compostas como alternativas . 9 return resul tado . Ou seja. CENTODUCATTE. observa-se um problema comum com bloqueios: baixa concorrência e. duas ou mais operações não acontecerão concorrentemente no buffer mesmo quando há uma possibilidade de paralelismo. 8 notifyAll().6 i tens ��. é possível que uma operação de inserção ocorra simultaneamente a uma de remoção se ambas acessarem elementos disjuntos no buffer. 7 resul tado = b u f f e r [ i t e n s ] . BALDASSIN. Caso os dois buffers estiverem vazios. Fonte: (RIGO.para execução. Nesta implementação. Caso o buffer 1 estiver vazio o sistema tentará remover o elemento do buffer 2. 2005). o bloco atômico será bloqueado até que ao menos um dos buffers contenha um elemento para poder ser removido. Uma implementação possível usando orElse para esta situação é mostrada na Figura 20. } 5 orElse 6 { x = buf fer2 . O método de remoção pode ser bloqueado (invocar retry) se o buffer estiver vazio.. Existem dois tipos de isolamento: atomicidade forte . 1 2 public void exemploOrElse ( ) { 3 atomic { 4 { x = buf fer1 . significando que somente uma transação será executada entre várias (HARRIS et al. remover ( ) . 2007) Níveis de isolamento O nível de isolamento está relacionado à interação entre código transacional e código não transacional. CENTODUCATTE. conforme mostrado na Figura 18. Por exemplo. } 7 } 8 } Figura 20: Uso da construção orElse. remover ( ) . suponha-se um sistema que remova elementos de um buffer. o sistema transacional tentará remover elementos entre dois buffers. BALDASSIN. Versionamento de dados O versionamento de dados lida com o gerenciamento das diferentes versões dos dados (originais e especulativas) acessados por uma transação. 2009). A versão original corresponde ao valor do dado antes do início da transação. CENTODUCATTE.3. causa condição de corrida e portanto o resultado é não-determinístico. 2007). consistência e isolamento. . A versão especulativa representa o valor intermediário sendo trabalhado pela transação. dentro e fora de uma transação. descritas anteriormente. satisfazendo as propriedades de atomicidade. No modelo com atomicidade forte o acesso a um dado compartilhado fora de uma transação é consistente com os acessos efetuados ao mesmo dado dentro da transação.(strong atomicity) e atomicidade fraca (weak atomicity) (BALDASSIN. Em contrapartida. 34 3. As implementações são construídas com dois mecanismos chaves: versionamento de dados e detecção/resolução de conflitos (RIGO.3.2 Implementação Um sistema de memória transacional deve garantir a consistência e integridade de execuções das transações. no modelo com atomicidade fraca o acesso a um mesmo dado compartilhado. BALDASSIN. descarta-se os especulativos e mantém-se os originais (BALDASSIN. Existem duas formas de versionamento de dados: adiantado/direto (direct update ou eager versioning) e atrasado/diferido (deferred update ou lazy versioning) (RIGO. os valores especulativos tornam-se os valores correntes e são armazenados. e a memória continua com os valores antigos. os dados que foram gravados na memória inicialmente deverão ser convertidos para suas versões antigas. CENTODUCATTE. através do undo log. e os valores originais são descartados. No versionamento de dados atrasado. Inicialmente. o conteúdo da variável X na memória corresponde ao valor 100 e os respectivos undo log e buffer estão vazios. Quando uma transação . No caso de uma transação falhar. Os dados são transferidos do buffer para a memória somente quando a transação for confirmada. 2007). BALDASSIN. No versionamento de dados adiantado.Caso a transação seja efetivada. enquanto que os valores antigos são armazenados em um undo log. 2009). Do contrário. o armazenamento de novos dados é realizado em um buffer local. os valores são armazenados diretamente na memória. Ilustra-se na Figura 21 um exemplo com ambos tipos de versionamento de dados. No versionamento atrasado a situação é oposta. Com o versionamento atrasado só é necessário descartar os valores especulativos. Por outro lado. Como pode ser observado na Figura 21. o versionamento adiantado altera imediatamente o conteúdo da memória e armazena o valor antigo localmente (undo log). conclui-se que o versionamento adiantado torna-se mais eficiente em casos em que a transação é confirmada. movendo para esta o valor antigo presente no undo log. pois os valores corretos já estão na memória. deve-se restaurar os valores corretos para a memória. No momento da efetivação da transação. quando a transação é cancelada. Nesse caso. pois o dado novo já está na memória.atribui o valor 77 à variável X. enquanto o versionamento atrasado somente necessita salvar o novo valor em memória local (buffer ). Uma situação inversa acontece em caso de cancelamento da transação. . que estão 35 armazenados no undo log. Já o versionamento atrasado precisa primeiramente mover o valor armazenado localmente para a memória do sistema. o versionamento adiantado precisa restaurar as mudanças efetuadas na memória. a única ação necessária no versionamento adiantado é invalidar o undo log. visto que transações confirmadas necessitam transferir os dados do buffer para a memória. BALDASSIN. 2009). A granularidade por nível de linha de cache provê um acordo entre . enquanto que transações canceladas não necessitam de nenhuma operação. A granularidade por nível de objetos pode reduzir o overhead em termos de espaço e tempo para detecção de conflitos. Essa granularidade pode ser em três níveis: objeto. ou seja. 2007). palavra e linha de cache (RIGO. Figura 21: Exemplo ilustrando versionamento adiantado (a) e atrasado (b). por outro lado. casos em que o sistema detectará conflitos quando duas transações operam em diferentes partes de um mesmo objeto. A granularidade por nível de palavras elimina a detecção de falsos conflitos. CENTODUCATTE. 2009) Detecção/Resolução de conflitos Diz-se que houve conflito entre duas ou mais transações quando essas acessam o mesmo dado compartilhado e um dos acessos é de escrita (BALDASSIN. Fonte: (BALDASSIN. O sistema transacional efetua a detecção de conflitos baseandose na granularidade de detecção de conflitos. esse nível permite detectar falsos conflitos. necessita-se de maior custo e espaço para a detecção. No entanto. Desta forma podese evitar que uma transação execute desnecessariamente. 2007). . Para exemplificar a detecção de conflitos de forma adiantada. pode cancelar transações. No modo de detecção de conflitos adiantado. No caso 2 tem-se uma operação de escrita depois de uma leitura. No entanto. A transação que escreveu (T2) faz com que a outra transação (T1) seja cencelada.a frequência de detecção de falsos conflitos e o overhead em termos de tempo e espaço. CENTODUCATTE. BALDASSIN. os cenários mostrados na Figura 22 serão considerados. o conflito é detectado no momento em que uma posição de memória é acessada. poderiam ser 36 confirmadas com sucesso. dependendo do progresso de outras. No caso 1. mas por outro lado. há dois modos de detecção de conflitos: adiantado/pessimista (pessimistic ou eager conflict detection) e atrasado/ otimista (optimistc ou lazy conflict detection) (RIGO. alterando seu protocolo de coerência. T1 e T2 manipulam conjuntos de dados disjuntos e portanto não há nenhum conflito. necessita-se de alterações na estrutura de hardware para prover a cache transacional. Assim como no versionamento de dados. Fonte: (RIGO. Quando T1 sofre efetivação. No caso 2. os cenários mostrados na Figura 23 serão considerados. No caso 3 não ocorre nenhum conflito. não ocasionando conflitos. T1 volta a executar e por sua vez cancela a transação T2. T2 lê uma variável escrita por T1. 2007) Na detecção atrasada o conflito é detectado somente no momento de efetivação da transação. desta forma. O caso 4 mostra a situação em que. as transações acessam um conjunto de dados disjuntos. No caso 1. após ser cancelada. Nesse exemplo. No entanto. este caso não gera situação de livelock. T1 volta a executar. pois T1 apenas lê uma variável que T2 está escrevendo e esta sofre efetivação após T1. De modo a exemplificar a detecção de conflitos de forma atrasada. diferentemente da detecção adiantada. após ser cancelada. CENTODUCATTE. Desta forma. T2 nota o conflito e é reiniciada. a efetivação de tais transações é indefinida. BALDASSIN. .O caso 3 mostra a situação em que. pode-se notar que as transações T1 e T2 estão em estado de livelock. essa abordagem permite que transações conflitantes prossigam na esperança do conflito não se efetivar de fato. Figura 22: Detecção de conflitos em modo adiantado em cenários transacionais. Fonte: (RIGO. podendo ser alterado para melhorar o desempenho de um programa sob determinada carga de trabalho (KRONBAUER. CENTODUCATTE. O gerenciador de contenção é o componente do sistema transacional responsável por resolver os conflitos dentre as transações concorrentes.porém. BALDASSIN. deve evitar starvation e livelock (BALDASSIN. 2009). ao passo que outras propostas tratam o problema como um aspecto modular do sistema. A resolução de conflitos deve ser efetuada de tal forma a garantir progresso do sistema. pois . não existe um consenso na comunidade de TM sobre qual estratégia para detecção/resolução de conflitos é a mais efetiva. 2007) A escolha do gerenciador de contenção pode influenciar no desempenho e consumo de energia de memórias transacionais. ou seja. Algumas propostas de TM possuem um método fixo para gerenciamento de contenção. poderia acontecer situação de starvation. 37 Figura 23: Detecção de conflitos em modo atrasado em cenários transacionais. Porém. Se T1 fosse muito longa essa poderia ser sempre cancelada por outras transações e nunca conseguir efetivar suas alterações. RIGO. conforme será mostrado no Capítulo 4. 2009). e alteraram o protocolo de coerência. Memória Transacional em Hardware As implementações de memórias transacionais em hardware (HTM) usualmente fazem o versionamento de dados e detecção de conflitos através modificações e extensões em alguns componentes da arquitetura computacional (BALDASSIN. e híbrida (BALDASSIN. chamada de cache transacional.3 Modelos de memórias transacionais As implementações de TM são comumente divididas em três modelos: hardware. Várias abordagens de HTM foram desenvolvidas após o modelo descrito por .3. As implementações nas três abordagens devem prover o versionamento dos dados manipulados pelas transações de forma atômica e isolada. 2009). Herlihy e Moss estenderam a arquitetura do conjunto de instruções de um processador base com 6 novas instruções. A primeira implementação de HTM foi desenvolvida por Herlihy e Moss em 1993 (HERLIHY.uma estratégia pode funcionar bem para algumas aplicações mas não para outras (BALDASSIN. adicionaram uma cache especial. software. 1993). e efetuar a detecção/resolução de conflitos entre transações. 3. Para dar suporte a transações.3. MOSS. 2009). 2009). OneTM (BLUNDELL et al. No entanto. As implementações em hardware têm como principais características garantir atomicidade forte como nível de isolamento e granularidade por linha de cache. as implementações em hardware ainda são consideradas complexas. 2007). VTM (Virtual Transactional Memory) (RAJWAR. A principal vantagem de HTM é o desempenho.. 2005).. 2004). 2007) e MetaTM (RAMADAN et al. UTM (Unbounded Transactional Memory) (ANANIAN et al.. procurando suprir as principais deficiências da proposta inicial... HERLIHY. PTM (Page-based Transactional 38 Memory) (CHUANG et al. LogTM (Log-based Transactional Memory) (MOORE et al. tornando inviável a adoção e . a qual restringia o número de posições acessadas pela transação (espaço) e a duração em que a transação poderia estar ativa. 2006). pelo fato de implementar as transações diretamente em hardware.. LAI. diferenciando-se entre si pelo hardware extra exigido e estratégia adotada para versionamento e controle de conflitos. 2006). As principais são: TCC (Transactional Coherence and Consistency) (HAMMOND et al. Essas propostas têm suporte para virtualização de espaço e tempo. 2005).Herlihy e Moss. Os sistemas de memória transacional em software usam barreiras de leitura e escrita para interceptar os acessos aos dados compartilhados e manter os . propondo uma alternativa em software ao mecanismo em hardware de Herlihy e Moss (HERLIHY.implementação efetiva em algum processador comercial (BALDASSIN. 1993). 2007). BALDASSIN. que aponta para o registro da transação detentora da palavra. visto que alterações na arquitetura computacional não fazem-se necessárias (RIGO. Memória Transacional em Software O modelo em software implementa as transações puramente em software. A implementação proposta mantém para cada palavra em memória compartilhada um registro de posse. tem-se uma maior flexibilidade na implementação aliada à execução em máquinas atuais e subsequentemente a portabilidade deste modelo. efetuação das alterações e liberação da posse. de 1993. Um conflito acontece caso alguma palavra já tenha sido adquirida por outra transação. CENTODUCATTE. 2009). TOUITOU. O termo Memória Transacional em Software (STM) foi cunhado por Shavit e Touitou em 1995 (SHAVIT. 1995). MOSS. Como vantagem dessa abordagem. O processo de efetivação das transações baseia-se na aquisição de posse de todas as palavras a serem alteradas. enquanto WSTM. A maioria dessas implementações trabalham com granularidade em nível de objeto. ASTM e RSTM são livres de obstrução. A partir desse importante . As primeiras implementações de STM são não-bloqueantes. OSTM (Object-based STM) (FRASER.. pois é o componente transacional responsável por determinar o progresso do sistema em situações de conflitos. OSTM e HaskellTM são livres de trava. 2005).conjuntos de leitura e escrita (BALDASSIN. WSTM (Wordbased STM) (HARRIS. o gerenciador de contenção tem um papel vital. entre as principais estão: DSTM (Dynamic STM) (HERLIHY et al.. HaskellTM (HARRIS et al. 2006). Constatou-se através de pesquisas que as abordagens transacionais em software não-bloqueantes apresentam baixo desempenho. Nas implementações livres de obstrução. Especificamente. Scherer III.. 2003). se comparadas à utilização de bloqueios explícitos (ENNALS. DSTM. FRASER. 2005) e RSTM (Rochester STM) (MARATHE et al. 2009). SCOTT. ASTM (Adaptive STM) (MARATHE. 2006). 2004). 2003). Existem dois tipos principais de implementações: não-bloqueantes e bloqueantes. exceto WSTM e HaskellTM que usam granularidade em nível de palavra. a maioria das implementações em software garantem apenas atomicidade fraca como nível de isolamento. Nessa abordagem. 2006). 2009). transações podem ser executadas em um dois modos: em . detecção e resolução de conflitos (BALDASSIN. Em especial.resultado a maioria das implementações propostas passaram a utilizar locks. e pela estratégia de versionamento de dados. KAPALKA. pois garantir atomicidade forte exigiria incluir barreiras também em código não transacional (BALDASSIN... As diversas implementações de STM se diferenciam principalmente pela granularidade de acesso permitido (palavra ou objeto). SHAVIT. GUERRAOUI. 2009). 2006). TL2 (Transactional Locking II) pela Sun (DICE. 2009). SHALEV. 2006). de maneira implícita. FETZER. TinySTM pelas universidades de Neuchâtel e de Dresden (FELBER. foram apresentadas: McRTSTM (Multi39 core RunTime STM) pela Intel (SAHA et al. devido a motivos de desempenho. Bartok-STM pela Microsoft (HARRIS et al. 2008) e SwissTM pela Escola Politécnica Federal de Lausana (DRAGOJEVIC. RIEGEL. Ao contrário de HTM. Memória Transacional Híbrida A abordagem híbrida busca combinar os modelos de software e hardware com intuito de obter melhor resultado com a união das duas abordagens. com alto desempenho... Contornar esse problema geralmente requer soluções que tornam as transações em hardware mais lentas do que o desejado (BALDASSIN. Nas primeiras implementações de memórias transacionais híbridas as transações são iniciadas em modo de hardware. 2009). DWARKADAS. 2006). 2006) (SHRIRAMAN et al. 2007) (MINH et al. mas usam o hardware para acelerar tarefas críticas. 2007). ADL-TABATABAI. Por exemplo. SCOTT. A principal característica dessas propostas é que as transações são sempre executadas em modo de software.hardware.. com ilimitados recursos (RIGO. Posteriormente. BALDASSIN. JACOBSON. Uma solução nas . as propostas de TM híbridas basearam-se na aceleração do software através do suporte executivo em hardware (SAHA. mas se os recursos de hardware forem exauridos a transação poderá ser reiniciada em modo de software (DAMRON et al. 2008). 2006) (KUMAR et al. 2007) (SHRIRAMAN. CENTODUCATTE.. a validação das transações é reconhecidamente um gargalo na maioria das STMs. ou software. O grande desafio nessa abordagem é quando existem transações concorrentes executando tanto em modo de hardware quanto em modo de software. (SAHA. se não empregados corretamente. 2009). Mostrou-se que mecanismos de sincronização baseados em bloqueios (locks) 40 são fáceis de usar em muitos casos. podendo ser potencialmente usado em outras tarefas (BALDASSIN.4 Observações finais Este Capítulo apresentou os principais conceitos relacionados à comunicação e sincronização em sistemas concorrentes. JACOBSON. que visam garantir a corretude das execuções concorrentes. A grande vantagem é que o hardware adicionado não é específico para TM. pois tira da responsabilidade do programador o modo como as sincronizações serão feitas. em ambiente de memória compartilhada. ficando a encargo do sistema que . ADL-TABATABAI. porém. e consequentemente são muito utilizado. Foram apresentados os problemas que podem ocorrer durante a comunicação entre fluxo de execuções de sistemas. e os mecanismos de sincronização. como feito por Saha et al. podendo levar o sistema a um estado de instabilidade.abordagens híbridas seria adicionar hardware para acelerar essa tarefa. 3. podem apresentar uma série de problemas. 2006). O mecanismo de sincronização por memórias transacionais garante maior abstração na codificação de programas paralelos. em consequência. pois essas podem ser executadas diretamente em processadores atuais. o sistema transacional facilita a codificação de programas paralelos. No entanto. dificultando assim. por implementarem o suporte executivo diretamente em hardware. Em relação as memórias transacionais. as STM têm como principais vantagens a flexibilidade e portabilidade da implementação.implementa as memórias transacionais garantir a sincronização em baixo nível. descritos no . além de suprir as dificuldades e limitações encontradas no uso de locks. relacionados aos mecanismos de sincronização em ambiente de memória compartilhada. mostrou-se que as implementações em hardware (HTM) têm como principal vantagem o desempenho. Por implementar as sincronizações em baixo nível. 4 TRABALHOS RELACIONADOS Este Capítulo apresenta os principais trabalhos que levam em consideração a medição do consumo de energia e/ou desempenho. a adoção e implementação efetiva em processadores comerciais. embora as implementações em software (STM) apresentem desempenho inferior em relação à HTM. este modelo é complexo de ser projetado. são atualmente alvo de muita pesquisa. Por outro lado. a partir de modificações na arquitetura computacional. A segunda. foi proposta pelos próprios autores. Bahar e Herlihy (2005) avalia o consumo de energia de HTM em comparação à locks (spinlock). 2002) para modelar um sistema com processadores UltraSparc II conectados por barramento. no qual há uma cache transacional completamente associativa para armazenar os valores especulativos. sendo pioneiro em avaliar o consumo energético em HTM. na qual. A primeira abordagem é padrão da HTM utilizada. Utiliza a plataforma de simulação SIMICS (MAGNUSSON et al. 1993). e sistema operacional Linux. 4.1 Reduzindo o consumo de energia em um sistema multiprocessado usando HTM O trabalho de Moreshet. assumindo dados de energia e latência para uma memória compartilhada off-chip.. MOSS. Duas diferentes abordagens para a HTM utilizada foram experimentadas. reexecuta as transações conflitantes em paralelo (baseado em backoff randômico). . a diferença entre ambas está no método utilizado para manipulação de conflitos em transações.Capítulo anterior. Sua implementação baseia-se no modelo original de HTM (HERLIHY. sendo um mecanismo para execução de modo serial de todas transações pendentes durante o o conflito. Apenas um microbenchmark (desenvolvido pelos próprios autores) com apenas uma configuração do sistema (quatro processadores) é utilizado para os experimentos. Em relação às HTM utilizadas. E. esta é uma abordagem pessimista. Embora os resultados obtidos neste trabalho mostram que HTM é eficiente em termos de consumo de energia. na qual há uma contenção do paralelismo. Utilizando Bahar e Herlihy (2005). 42 4. Tal resultado deve-se a significativa fração de energia consumida pela hierarquia de memória. não é descrito como é implementado o mecanismo de execução serial das transações conflitantes. No entanto. o trabalho apresentou alguns problemas que tornam seus resultados pouco convincentes. anteriormente.Através dos resultados obtidos neste trabalho mostrou-se que a versão utilizando locks consumiu 10x mais energia que as abordagens de HTM utilizadas. Bahar e Herlihy (2006) apresenta uma extensão do trabalho de Moreshet.2 HTM x locks: uma comparação de desempenho e consumo de energia O trabalho de Moreshet. a que utilizou a execução serial para tratamento de conflitos mostrou-se mais eficiente em termos de energia. descrito . por considerar que as aplicações do SPLASH-2 possuem taxas de conflitos baixa. reduzindo assim o consumo de energia e maximizando a performance. reduziu-se os acessos à cache e a memória principal. 1995). com duas . um conflito ainda resulta em retornar ao estado anterior. o sistema transacional voltará a emissão de transações em paralelo. No entanto. constatou-se através dos resultados obtidos no benchmark SPLASH-2 que na maioria das aplicações onde substitui-se os locks por transações. o sistema transacional irá esperar uma transação completar antes de outra começar sua execução. Após o período conflitante. Entretanto.a mesma HTM e plataforma de simulação. durante alta contenção. foi utilizado configurações para simular um microbenchmark.. Com o sistema transacional de execução serial. Inicialmente. em vez de re-executar as transações depois do conflito. avalia o consumo de energia e desempenho de HTM em comparação à locks (spinlock) através de quatros aplicações do benchmark SPLASH-2 (WOO et al. Neste trabalho é apresentado maiores detalhes em relação à execução serial das transações conflitantes. visto que no trabalho anterior apenas foi citado esse novo mecanismo. a memória transacional utilizando-se da execução serial para os casos de conflito superou em termos de performance e eficiência energética a memória transacional que utilizou a técnica de backoff para conflitos. ambas implementações de memória transacional (backoff e serial) superaram em termos de desempenho e eficiência energética à versão utilizando locks. são dados poucos detalhes em relação ao . a produtividade do sistema pode ser reduzida. o modo de execução serial das transações conflitantes mostra-se conservador. para outros casos. Porém. no melhor caso.diferentes cenários de conflitos. cerca de 10x mais. em outra configuração. a versão transacional serial mostrou-se ligeiramente inferior em relação à versão transacional utilizando backoff. Desta forma. No entanto. Em uma das configurações do microbenchmark. Através dos resultados mostrados neste trabalho verificou-se que a abordagem de HTM é promissora em termos de desempenho e energia. A execução serial para transações conflitantes em ambientes de alta contenção é eficiente em termos de energia. em termos de desempenho. porém. Nas duas configurações do microbenchmark. incorrendo em penalidades no desempenho. árvore de pesquisa binária. utilizando-se da aplicação Sendmail como base. árvore B e lista ligada. conforme aumentou-se o número de . as seguintes constatações podem ser feitas. utilizou-se de estruturas de dados comumente utilizadas em muitas aplicações: hashtable. 4. No entanto. Utilizou-se da plataforma IBM X Series 445 SMP com 16 processadores Xeon com 2.2 GHz para execução das aplicações. tornando novamente os resultados pouco convincentes. Dois experimentos com base em aplicações diferentes foram realizados. No segundo.microbenchmark e suas duas configurações e a avaliação do modo serial é feita somente neste microbenchmark. Para o primeiro experimento. avaliou-se o desempenho de STM e locks em uma aplicação não sintética. observou-se através dos resultados que a versão de STM inicialmente (utilizando 1 processador) obtém menor performance em comparação as duas implementações de locks (grão fino e grão grosso).3 McRT-STM x locks: uma comparação de desempenho No trabalho de Saha et al (2006) é mostrado um estudo de avaliação de desempenho entre a implementação McRT-STM e locks. com base nos resultados obtidos. Na aplicação hashtable. No 43 primeiro. verificouse que a STM obtém melhor desempenho em comparação à locks quando a proporção de atualizações é baixa. a STM apresentou desempenho ineficiente. o desempenho da STM aproximou-se da versão versão de locks que obteve maior desempenho (grão fino). Na utilização de 16 processadores. para altas taxas de atualização.processadores. o desempenho da STM variou conforme o número de atualizações na lista. Contudo. Na aplicação árvore de pesquisa binária balanceada. a STM mostrou melhor desempenho em comparação à locks (grão fino e grão grosso) mesmo com altas taxas de atualizações. mesmo com altas taxas de atualização. limitando a concorrência. Na utilização da árvore de pesquisa binária sem balanceamento observou-se que a STM apresentou melhor desempenho em comparação à locks. Na aplicação lista ligada classificada.8x menos eficiente em termos de performance em relação à locks (grão fino). o balanceamento propaga mudanças na raiz da árvore. devido a árvore B resultar em poucos cancelamentos de transações. Na árvore B. Com . E. Isto porque o balanceamento da árvore propaga mudanças em toda árvore e aumenta o número de cancelamento das transações. a STM foi cerca de 1. analisou-se a utilização de STM na aplicação. a STM apresentou melhor desempenho. visto que a STM apresentou desempenho inferior em relação à locks. devido a seção crítica representar um tempo significante. a memória transacional apresentou desempenho inferior à locks. verificou-se que a aplicação Sendmail (baseada em locks) gasta cerca de 10% de seu tempo de execução em seções críticas. buscando redução de tempo de execução para a seção crítica. Em relação ao segundo experimento.baixas taxas de atualização. não fornecendo desta forma nenhuma simultaneidade para as operações de atualização. Na lista ligada não classificada. em cenário de alta contenção. assim. . o desempenho torna-se ligeiramente inferior a locks. Em todos os casos. mas com o aumento de atualizações. verificouse que a STM se equiparou em termos de desempenho em relação à versão utilizando locks. Os resultados obtidos para as aplicações lista ligada e árvore de pesquisa binária mostraram a importância de um bom gerenciador de contenção no sistema transacional. devido ao aumento do número de transações canceladas. devido a todas inserções serem feitas na frente da lista. Os testes foram realizados utilizando-se de uma a 8 threads para cada abordagem. Esse resultado preliminar fornece evidências que até mesmo para aplicações comerciais. BENINI. a STM e locks são semelhantes em termos de desempenho. conhecido como MPARM (LOGHI. O processo de caracterização foi conduzido em um ambiente simulado amplamente usado na literatura. 2008). As aplicações utilizadas na caracterização fazem parte do pacote de benchmark STAMP (CAO MINH et al. 2004). Foram utilizadas as 8 aplicações presentes no pacote. 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. PONCINO. os acessos feitos a memória compartilhada não são retidos na cache. Segundo. visando representar diversos cenários transacionais . disponibilizado pela Universidade de Standford. Em relação a plataforma utilizada duas observações fazemse necessária. visto que a implementação do barramento usado não possui suporte para coerência de cache. as memórias empregadas (tanto privada como compartilhada) são baseadas na tecnologia SRAM (Static Random Access Memory). Primeiramente.. com diferentes configurações. e posteriormente. uma transação é postergada por um tempo (exponencial ou linear) proporcional ao número de cancelamentos. tempos em transação. SHAVIT. 2006). SHALEV. e graus de contenção. utilizou-se de apenas 1 processador nos experimentos. foram utilizados 8 processadores. De igual modo. Os experimentos realizados foram executados na plataforma de simulação com dois cenários diferentes. possibilitando assim. Duas estratégias do gerenciamento de contenção são providas. configurada de dois modos (ambos usados nos experimentos): TL2-lazy (versionamento atrasado) e TL2-eager (versionamento adiantado). A implementação da STM utilizada nos experimentos foi a TL2 (DICE. tamanho do conjunto de leitura e escrita. para que os custos devidos aos cancelamentos das transações fossem contabilizados. . Inicialmente. O procedimento de medição de energia foi dividido pelos componentes básicos de uma STM.com diferentes tamanhos de transação. avaliar quais os elementos mais custosos e orientar o projeto do algoritmo de forma a otimizá-lo. baseadas na técnica conhecida como backoff : após três cancelamentos consecutivos. uma versão sequencial (não utilizando-se de transações) será executada para comparação à STM. na utilização de 1 processador. Na utilização de 8 processadores. os autores propuseram a .Mostrou-se através dos resultados dos experimentos que a implementação que utiliza versionamento adiantado (TL2-eager) tem um custo de energia ligeiramente menor do que a técnica com versionamento atrasado (TL2-lazy). o custo total de energia chega a cerca de 50x o do caso sequencial. o custo total introduzido pelas transações pode chegar perto de 5x. no emprego do tempo de espera exponencial. De modo geral. No entanto. Em uma aplicação específica do pacote de benchmark. as duas configurações de backoff (exponencial e linear) foram contabilizadas. além das diferentes técnicas de versionamento de dados. em relação a execução sequencial. observou-se que para aplicações com alta taxa de cancelamento. para algumas aplicações. o custo de backoff passa a prevalecer. utilizando-se de TL2-lazy e tempo de espera exponencial. nos casos em que o esquema de espera linear é usado. devido ao alto 45 consumo de energia em casos de alta contenção. Porém. Com base nos resultados providos pela caracterização. o custo de cancelamentos domina. podendo ser usada em qualquer STM na qual o gerenciador de contenção adote políticas de resolução de conflitos baseada em espera. em média de 45%. Os experimentos utilizando-se da estratégia descrita. através da redução de sua frequência e voltagem. chegando a 87% de redução para uma aplicação específica. 4. A estratégia funciona da seguinte maneira: antes de entrar no modo de backoff.utilização de uma estratégia que visa reduzir o consumo em casos em que estados de espera são induzidos por cancelamentos de transações. a frequência e voltagem originais são restauradas. O custo para alternância em diferentes estados no processador é rápido. A estratégia proposta é baseada na técnica conhecida como DVFS (KAXIRAS. requerendo apenas 1 ciclo por mudança. MARTONOSI. obtiveram uma redução efetiva do consumo de energia para as aplicações com alto grau de contenção. Quando o tempo de backoff termina. O processador então cumpre seu tempo em estado de espera (linear ou exponencial) em modo de baixa potência. como resultado. o processador correspondente é colocado em modo de baixo consumo de potência. 2008).5 Avaliação de desempenho em gerenciadores de contenção . na plataforma utilizada. 8 GHz. Precisamente. Highlander. Greedy. Especificamente. Eruption. Foram realizadas algumas modificações na biblioteca de modo a permitir que diferentes gerenciadores de contenção possam ser associados a diferentes transações ou a diferentes objetos transacionais. Polkaruption e Whpolka. foi alterado a macro que delimita o início da transação. em dois modos: bloqueante e não bloqueante. os seguintes gerenciadores foram avaliados: Aggressive. O gerenciador pode desta forma ser associado ao objeto que encapsula a estrutura de dados transacional.com STM O trabalho de Kronbauer e Rigo (2009) avalia diferentes estratégias de gerenciadores de contenção em STM. Killblocked. fazendo com que recebesse como parâmetro um valor enumerado capaz de identificar o gerenciador de contenção a ser usado. um sistema baseado no processador Intel Core 2 Duo a 2. Polka. e diferentes gerenciadores de contenção podem ser associados a diferentes estruturas de dados ou mesmo a diferentes operações em uma mesma estrutura de dados. Três diferentes sistemas computacionais foram utilizadas para as execuções. O primeiro. O segundo um sistema baseado no processador Intel . Karma. com 2 GB de memória RAM. em termos de desempenho. Utilizou-se da versão 3 da biblioteca RSTM. Algumas afirmações podem ser feitas com base nos resultado obtidos. O terceiro. do benchmark disponível junto a implementação original da biblioteca RSTM. como aplicação base para os experimentos. pois a versão 3 da RSTM somente tem suporte para a plataforma SPARC. as árvores foram geradas de maneira a simular diferentes cenários (baixa.4 GHz e com 4 GB de RAM. Os tipos de operações nas árvores foram particionados igualmente.Core 2 Quad. um terço inserções e um terço remoções. Necessitou-se portar a biblioteca RSTM para arquiteturas x86 de 32 bits. O número de threads foi variado ao longo das execuções do benchmark. mista e alta contenção).6). Para . Todos os sistemas utilizaram como sistema operacional uma distribuição Linux padrão (kernel 2. Para assegurar diferentes padrões de acesso a diferentes estruturas de dados. um sistema com dois processadores Intel Core 2 Quad a 2 GHz e 4 GB de RAM. a 2. de uma thread até o 46 número de threads de execução igual a quatro vezes o número de núcleos de processamento no sistema. sendo um terço buscas. Utilizou-se da implementação de árvores balanceadas do tipo vermelha-epreta. Notou-se através dos resultados obtidos que não há um gerenciador de contenção ideal a ser utilizado como escolha padrão. o gerenciador Aggressive novamente apresentou o melhor resultado. o gerenciador Killblocked apresentou em todos os casos o melhor desempenho. tanto no cenário de alta quanto no cenário de baixa contenção. tanto em ambientes de alta como baixa contenção. Sob baixa contenção. Para o sistema Intel Core 2 Quad verificou-se que sob alta contenção. verificouse . Porém. em termos de performance. o gerenciador de contenção Aggressive foi o que apresentou melhores resultados. No sistema Intel Dual Core 2 Quad. quatro gerenciadores apresentaram o melhor desempenho. a implementação não-bloqueante da STM utilizada apresentou-se ligeiramente inferior em relação a versão bloqueante.o sistema Intel Core 2 Duo. na utilização de 4 ou mais threads. De maneira geral. Karma. Estes foram Killblocked. HERLIHY. o gerenciador Aggressive ofereceu o melhor desempenho de modo geral. reafirmando os resultados encontrados em (GUERRAOUI. POCHON. Eruption e Whpolka. Sob contenção mista. especialmente quando o número de threads excede o número de núcleos de processamento. 2005). No segundo. pacote de benchmark. 4. como o consumo de energia. Os experimentos foram realizados em dois cenários. pois o benchmark utilizado não prove uma versão baseada em locks para as aplicações. no entanto. metodologia e implementação de STM.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 comparação à locks. descrito na seção anterior. As aplicações baseadas em locks foram implementadas como um típico mecanismo de spinlock. apresentada no trabalho de Baldassin et al (2009). Mostrou-se neste trabalho que os gerenciadores de contenção representam uma área interessante para a busca pela melhoria de desempenho. No primeiro cenário. utilizando a mesma plataforma de simulação. não foram contabilizados os ciclos e energia desperdiçados devido a espera ocupada. Foi substituído as marcações de transações pelas operações de aquisição e liberação do lock global. os ciclos e .que a escolha ideal do gerenciador de contenção varia conforme o nível de contenção e plataforma de hardware. novos fatores também devem ser considerados na avaliação destes. em relação à implementação baseada em locks. o desempenho da STM mostrou-se inferior em relação à utilização de locks. a abordagem utilizando-se de locks superou a STM em energia 47 e desempenho. No entanto. em praticamente todas aplicações. a utilização de STM foi em média 3x mais ineficiente em relação aos locks. chegando cerca de 22x em uma aplicação específica. a utilização de STM pode se tornar atraente dependendo dos custos relacionados as penalidades dos locks. No . Além disso. a diferença entre o desempenho de ambas abordagens poderia ser reduzido quando incorrer penalidades altas para o mecanismo de locks. de modo geral. no entanto. No segundo cenário. a STM mostrou-se competitiva em termos de energia e desempenho. em especial para aplicações com taxas de conflitos baixa. Algumas afirmações podem ser feitas com base nos resultados obtidos. para algumas aplicações. No primeiro cenário. através de penalidades em ciclos (variando de 1k a 10k ciclos) quando o bloqueio não pode ser adquirido prontamente.energia gastos na espera ocupada foram contabilizados. com baixas taxas de conflito. Em aplicações com altas taxas de conflitos. demonstrou-se que para algumas aplicações transacionais. mesmo que elevadas penalidades sejam impostas. memórias. DE MICHELI. 4. As NoCs permitem elevado grau de paralelismo na comunicação. avalia o desempenho e consumo de energia de diferentes políticas de gerenciadores de contenção. uma alternativa as interconexões tradicionais como barramentos e chaves crossbar (BENINI. para aplicações com alta contenção. pois os links da rede podem operar de modo simultâneo sobre diferentes pacotes de dados.7 Avaliação 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 comparação ao mecanismo de locks. Apesar . Além disso. sendo esta. A interconexão entre os núcleos de processamento foi baseada em uma arquitetura de rede chamada NoC (Network on Chip). Cada roteador é associado a algum elemento do conjunto da rede (processadores. MAHADEVAN. a utilização de locks mostra-se a melhor abordagem. Uma NoC é uma estrutura de comunicação formada por diversos roteadores conectados entre si de acordo com determinada topologia. 2006). 2002) (BJERREGAARD. entre outros). em um sistema embarcado multiprocessado.entanto. 2048 e 8192 bytes. todos operando sobre frequência de 100 MHz. arbitragem Round-robin e frequência de operação de 100 MHz. caches e processadores do sistema. sendo essas completamente associativas e baseadas no protocolo de coerência MSI baseado em diretório. enquanto que a energia das memórias e . 1024. MAHADEVAN. 2002).. chaveamento Wormhole. os limites físicos impostos pelo fio. questões relacionadas a escalabilidade e largura de banda apontam para a NoC como a melhor alternativa para futuras gerações de processadores many-core (BJERREGAARD. memórias. 4. topologia Grade (mesh). 16 e 32 processadores.das soluções tradicionais (barramentos e crossbar) apresentarem vantagens em termos de simplicidade. A configuração da NoC é baseada no roteamento XY. WAGNER. O consumo de energia foi obtido levando-se em consideração a energia da rede. compatibilidade e latência. 8. BRIÃO. Os tamanhos de cache L1 usadas foram de 512. 2006). 2007). O sistema computacional utilizado na realização dos testes utilizou-se de 2. A implementação e os experimentos realizados neste trabalho foram feitos na plataforma virtual SIMPLE (BARCELOS. A energia da NoC foi calculada através da biblioteca Orion (WANG et al. 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 aplicação. no entanto. Para avaliar o comportamento do sistema para o caso em que não há paralelismo disponível para as transações. LeeTM (ANSARI et al. JOUPPI.. Com a modificação realizada. o gerenciador realizados para aplicações de baixa . uma aplicação que utiliza de alta demanda de sincronização durante a maior parte de sua execução foi testada. a quantidade de paralelismo que a TM pode explorar é a mesma que a versão baseada em locks. Nos experimentos contenção. este paralelismo é difícil de expressar utilizando-se do mecanismo de locks. desenvolveu-se neste trabalho uma modificação do LeeTM para forçar artificialmente a contenção. três benchmarks foram utilizados: Multiplicação de Matrizes. A aplicação LeeTM possui paralelismo intrínseco. Esta aplicação LeeTM com inibição do paralelismo é chamada de LeeTM-IP. 48 Para os experimentos em aplicações de baixa contenção. Codificador JPEG e Estimação de Movimento. 1996). 2008). Para o cenário de alta contenção.das caches foi calculada com a ferramenta Cacti (WILTON. indicando que a potência média também foi reduzida. e. 10000 ciclos (para 16 processadores) e 25000 (para 32 processadores). mostrou-se que na maioria dos casos para até 4 processadores.4 e 8 processadores). Em relação à energia consumida.de contenção da memória transacional utilizada baseou-se na técnica de backoff com valores fixos. em termos de desempenho. . nas três aplicações e em todas configurações testadas. os ganhos de energia ultrapassaram os de desempenho. chegando a 30% no melhor caso. Através dos resultados obtidos para o cenário de baixa contenção. a memória transacional apresentou-se ligeiramente inferior em relação aos locks. a memória transacional apresentou-se eficiente em comparação aos locks. os resultados de energia seguem os ganhos de performance à medida que o número de processadores do sistema foi aumentado. De maneira geral. O tempo de espera usado foi de 5000 ciclos (para 2. em muitos casos. Na utilização a partir de 6 processadores obtevese um aumento de performance da memória transacional à medida que o número de processadores aumentava. apresentando reduções de energia em todos os casos. superando os locks em todos os casos. encontrou-se o parâmetro que dá o menor tempo de execução para cada política de backoff de cada configuração do sistema. exponencial e linear randômico) para diferentes configurações do sistema (número de processadores). T0 envia o sinal para T1 permitindo que ela reinicie a execução. utilizando-se da aplicação LeeTM. De modo a exemplificar o funcionamento. Para isso. T0 então adiciona T1 em sua lista de transações abortadas.No cenário de alta contenção. Como alternativa ao encontro da melhor heurística para ajustar o tempo de espera de backoff. como primeiro experimento. uma transação pode esperar . chamada de Abort Handshake. foi feita uma análise para encontrar o valor ótimo para o tempo de espera de backoff (fixo. Quando finalizar a execução. Afim de evitar situações de deadlock. A solução proposta é baseada em sinalização entre transações de forma que a transação abortada seja notificada quando for seguro reiniciar para evitar que ocorra o mesmo conflito. os autores propuseram uma nova estratégia de gerenciamento de contenção. quando a transação T1 aborta após conflitar com a transação T0. T1 envia uma mensagem sinalizando seu aborto à T0 e aguarda até receber o sinal de T0 notificando o momento de sua re-execução. uma transação que tenha abortado outra pode se abortada por uma terceira transação. memória transacional com o mecanismo Abort Handshake e memória transacional com os valores ótimos para cada política de backoff (fixo. uma irá notificar a outra após o commit e assim sucessivamente. Nenhuma das políticas de . é possível que a transação abortada nem mesmo solicite o bloco conflitante novamente se a decisão de requisitar o bloco depender de dados alterados por uma terceira transação neste meio tempo. Além disso. Em seguida. É uma solução conservadora já que a transação que abortou pode ter trabalho para executar de forma independente antes de solicitar o bloco conflitante novamente. utilizando locks. Esta solução serializa por completo a execução de duas transações quando uma delas aborta ao permitir que esta reinicie apenas após o commit da outra. Além disso. realizou-se um experimento em ambiente de alta contenção comparando as aplicações LeeTM e LeeTM-IP. Como resultados deste experimento verificou-se que não houve vantagens em termos de desempenho e energia na versão das aplicações utilizando locks. exponencial e linear randômico).49 apenas por uma transação de maior prioridade. para mais de 4 processadores. backoff pode ser escolhida como vencedora, pois todas tiveram resultados parecidos e a melhor depende de cada caso. Em situações de alta contenção, o backoff exponencial aumenta muito o tempo de espera das transações, 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 reduções do tempo de execução em 20% e redução de energia de 53%, se comparados com a melhor política de backoff em cada caso. Entretanto, para alguns casos, algumas peculiaridades podem afetar o desempenho do Abort Handshake. Embora que, na utilização de 2 processadores o mecanismo Abort Handshake foi inferior em termos de energia e desempenho em relação a todas políticas 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 comparação a locks e a memória transacional processadores. Sendo com backoff, na utilização de 32 então necessário, em um estudo futuro, analisar a eficiência do mecanismo Abort Handshake utilizando-se mais de 32 processadores. 4.8 Comparação entre implementações de semáforos e memórias transacionais em relação ao consumo de energia O trabalho de Mittal e Nitin (2011) avalia o consumo de energia e taxa de cache miss de semáforos (spinlock e bloqueante) e memórias transacionais, na memória cache compartilhada. Utilizou-se de uma arquitetura computacional multicore, com 4 cores, cada um com sua memória privada e duas memórias caches compartilhadas. A arquitetura foi simulada com base no conjunto de ferramentas SimpleScalar (BURGER; AUSTIN, 1997). Três benchmarks foram utilizados como aplicações bases para os testes: Árvores Rubro-Negras, Transformada Rápida de Fourier e SPLASH-2 (WOO et al., 1995). 50 De modo geral, os resultados obtidos nos testes realizados mostraram que a sincronização por semáforos bloqueantes obteve menos cache miss em comparação à spinlocks e transações. Em termos de consumo de energia, memórias transacionais e semáforos bloqueantes têm um consumo equivalente, porém muito eficiente em comparação à spinlocks. Apesar de indicar que a sincronização por semáforos bloqueantes apresenta melhores taxas de cache miss em comparação à spinlocks e transações, e que em termos de energia se equipara à memórias transacionais, o trabalho apresenta alguns problemas que tornam seus resultados pouco convincentes. Não é descrito quais aplicações do benchmark SPLASH-2 foram utilizadas, apenas utilizou-se de uma arquitetura computacional (4 cores), e não foi explicitado o tipo de memória transacional usada. 4.9 Observações finais Este Capítulo apresentou as principais pesquisas que avaliam o consumo de energia e/ou desempenho de aplicações, relacionadas a mecanismos de sincronização em ambiente de memória compartilhada. Diferentes técnicas e implementações de mecanismos de sincronização foram avaliadas através dos oito trabalhos descritos anteriormente. Nesta perspectiva, as seguintes constatações podem ser feitas, com base nos resultados obtidos. Observou-se que o nível de contenção influencia consideravelmente o desempenho e consumo de energia das aplicações. De modo geral, altas taxas de contenção incorrem em custos adicionais em termos de energia e penalidades em desempenho resolução de conflito das nas memórias transacionais, devido a apresentaram desempenho inferior e maior consumo de energia se comparadas a utilização de locks. em aplicações com baixo nível de contenção. em cenários de alta contenção. No entanto. de modo geral. No entanto. 5 CONCLUSÕES E TRABALHOS FUTUROS .transações conflitantes e suas re-execuções. superando a eficiência energética e abordagem locks em muitas vezes em termos de desempenho. por outro lado. superando em desempenho e eficiência energética a sincronização por locks. mostraram-se eficientes tanto em cenários de alta quanto baixa contenção. Para o cenário de alta contenção. as implementações de STM mostraram-se competitivas. verificou-se que não há um gerenciador de contenção ideal a ser utilizado em todos os casos. as estratégias utilizadas pelo gerenciador de contenção em transações garantem a efetivação de reduções de custos adicionais de energia e penalidades no desempenho. as implementações de STM. em muitos casos. As implementações de HTM. na maioria dos casos. Em relação a comparação entre os mecanismos de sincronização. a escolha ideal do gerenciador de contenção varia conforme o nível de contenção e plataforma de hardware. Porém. No entanto. o controle sobre a sincronização é feito automaticamente pelo sistema transacional. diferentemente da sincronização por locks. esta abordagem de sincronização é propensa a erros. visando suprir as dificuldades e limitações encontradas no uso de locks.Este trabalho apresentou as principais características da programação paralela em ambiente de memória compartilhada. especificamente. e este implementa a sincronização em baixo nível. o que facilita a programação. Nas memórias transacionais. visando-se a redução do consumo de energia em sistemas computacionais. pois o programador apenas precisa definir quais serão os blocos de código a serem executados pelo sistema transacional. A principal contribuição deste trabalho foi analisar diversas pesquisas que . e relacionou-se mecanismos de sincronização utilizados para garantir a integridade e consistência da comunicação entre execuções concorrentes à computação sustentável. e pode apresentar instabilidade no sistema. Mecanismos de sincronização em ambiente de memória compartilhada têm sido tradicionalmente realizados através de métodos baseados em bloqueios (locks) explícitos pelo programador. Memórias Transacionais surgiram como uma alternativa à sincronização baseada em locks. as implementações em software apresentam desempenho inferior e maior consumo de energia se comparadas à sincronização baseada em locks. As implementações em hardware mostram-se eficientes na maioria dos casos e cenários. em cenários de alta contenção. a eficiência do desempenho e consumo de energia de memórias transacionais em software (STM) é influenciada diretamente pelo ambiente de execução. No entanto. De modo geral. Apesar de terem se .avaliaram o consumo de energia e/ou desempenho sobre mecanismos de sincronização em memória compartilhada. focando-se especialmente em implementações de memórias transacionais comparadas à sincronização baseada em locks. verificou-se que a eficiência das memórias transacionais varia conforme sua implementação e o cenário de execução (alta e baixa contenção). Para este tipo de cenário. porém. mostrando-se a melhor abordagem de sincronização em muitos casos. as estratégias de gerenciamento de contenção são responsáveis por garantir o progresso das transações conflitantes e por efetivar reduções de penalidades no desempenho e no consumo de energia. Através desta análise constatou-se que a sincronização por memórias transacionais é promissora. em termos de consumo de energia e desempenho. visto que o gerenciador de contenção é um componente essencial . Tal avaliação sobre mecanismos de sincronização seria de suma importância.mostrado inferiores em relação aos locks em cenários de alta contenção. a avaliação de várias estratégias de gerenciamento de contenção sob o mesmo contexto. Por se tratar de uma abstração nova. grande parte das pesquisas avaliam poucas estratégias sob um mesmo contexto. especialmente quando avalia-se o consumo de energia. seria de grande valia. Não encontrou-se na literatura pesquisas que avaliam o comportamento de memórias transacionais e outros mecanismos de sincronização para ambientes de memória compartilhada em relação à arquiteturas manycore. e ainda há muito o que ser pesquisado para melhor caracterizá-la. sendo superiores em desempenho e eficiência energética em muitos casos. memórias transacionais ainda são 52 essencialmente tema de pesquisa. pois este tipo de arquitetura é tendência para um futuro próximo. Embora existam diversas estratégias e pesquisas sobre gerenciamento de contenção. Desta forma. as STM mostram-se competitivas aos locks em aplicações de baixa contenção. ANANIAN. S. (AFIPS ’67 (Spring)).. sendo esta análise de grande importância para o desenvolvimento efetivo de sistemas comerciais baseados em memórias transacionais.. ACM. Foundations of multithreaded. A maioria das avaliações de memórias transacionais são baseadas em benchmarks ou até mesmo microbenchmarks. G. Validity of the single processor approach to achieving large scale computing capabilities. . New York. KUSZMAUL. M. 1967. Unbounded Transactional Memory. S.. Portanto. .. E.316– 327. a caracterização de memórias transacionais em aplicações não sintéticas poderia ser avaliada em trabalhos futuros. IEEE Computer Society. 2005. USA. DC. 53 REFERÊNCIAS AMDAHL. 1967. K. 2005. . C. . NY. Dentre as pesquisas analisadas por este trabalho. USA. In: INTERNATIONAL SYMPOSIUM ON HIGH-PERFORMANCE COMPUTER ARCHITECTURE. LEISERSON.. G. parallel.no contexto do sistema transacional. 11. Proceedings. ASANOVIC. and distributed . In: APRIL 18-20. Washington. apenas uma entre as oito avaliou o comportamento de memórias transacionais em uma aplicação comercial. 1967. p. p. LIE. R. Proceedings. SPRING JOINT COMPUTER CONFERENCE. ANDREWS. C. C.483– 485. B. . Brasil. KOTSELIDIS. R.. 2010 22ND INTERNATIONAL SYMPOSIUM ON. IEEE Comput.. S CAMARGO.n.l. ANSARI. I. CENTODUCATTE. G. Towards a power-aware application level scheduler for a multithreaded runtime environment. A. C. SP. 2010.. C. KIRKHAM. JARVIS. In: IN PROCEEDINGS OF THE 8TH INTERNATIONAL CONFERENCE ON ALGORITHMS AND ARCHITECTURES FOR PARALLEL PROCESSING. G. KLEIN. E. p. 2008. Lett. Characterizing the Energy Consumption of Software Transactional Memory.].. de. Lee-TM: a non-trivial benchmark suite for transactional memory. Campinas.. PILLA. 2010. Jogos Computacionais e Consumo de Energia. [S. Tese (Doutorado em Ciência da Computação) — Universidade Estadual de Campinas. 2009.]. Boston: Addison Wesley. 2008. DC.. J.. A.l. R.. A hybrid memory organization . C. 2000. A.. LUJáN. Anais. AZEVEDO.. de. WATSON. Anais. CAVALHEIRO. In: COMPUTER ARCHITECTURE AND HIGH PERFORMANCE COMPUTING WORKSHOPS (SBAC-PADW). Washington. K. USA. WAGNER. BALDASSIN.. F. Archit. M. July 2009. ICA3PP. F. ARAUJO. D.: s. . .43–48. BRIÃO. BARCELOS. v. p. ARAUJO. P. M.. Explorando Memória Transacional em Software nos Contextos de Arquiteturas Assimétricas. [S.56–59.programming.n. . . BALDASSIN.: s. W.8. M. Computer.. p. S. (SBCCI ’07). C. June 2006.. p.. New York. News.. v. 2007. v. 2007.]. version 2. USA.. DE MICHELI. New York. USA. SIGARCH Comput. 2007. CAO MINH. . . MAHADEVAN. USA. T. NY. p. . G.13–25. Anais. T. In: COMPUTER ARCHITECTURE... CHUANG. . NY. ACM. 20. ACM Comput. . BLUNDELL. S.. M. January 2002. In: IISWC ’08: PROCEEDINGS OF THE IEEE INTERNATIONAL SYMPOSIUM ON WORKLOAD CHARACTERIZATION.. C. AUSTIN.n.282–287. .to enhance task migration and dynamic task allocation in NoCbased MPSoCs. MARTIN.l. [S. USA. LEWIS. Proceedings. W. Archit. K. Surv. BURGER.35. G. 2008. SAMPSON. NY. BJERREGAARD. Networks on Chips: a new soc paradigm.70–78. 2007. DEVIETTI.. 2008. USA. E.0.. In: INTEGRATED CIRCUITS AND SYSTEMS DESIGN.38. J.25. NY. June 1997.24–34. J. 54 BENINI. p. A survey of research and practices of Network-on-chip. v. New York. C. The SimpleScalar tool set. M... STAMP: stanford transactional applications for multi-processing. M. ACM. New York. D. VENKATESH. CHUNG. OLUKOTUN. (ISCA ’07).. Making the fast case common and the uncommon case simple in unbounded transactional memory. J. KOZYRAKIS.: s. K. NARAYANASAMY. L. CA. . C. Proceedings.. Los Alamitos. 34.. ACM. . 6. ELPHICK.]. New York. H. Unbounded page-based transactional memory. M. (ASPLOS-XII). P. Y. POKAM. System deadlocks. DICE. ENNALS. . Stretching transactional memory. ACM. 12. n. A.. J. R. New York.. 2009. GUERRAOUI.. USA. A. 2006. USA. Proceedings.. NY.. FEDOROVA... p. NY. [S. New York. 2006. 12. . E. MOIR. R. Java: como programar.155–165. NY. D. SHALEV.. 2006.. USA.3. . NUSSBAUM. M.l.. v.. M.194–208. DRAGOJEVIC. Proceedings. 1971.l. 2009. Proceedings. p. p.].. In: INTERNATIONAL SYMPOSIUM ON DISTRIBUTED COMPUTING (DISC 2006).ed. SHAVIT. G. (ASPLOSXII).. A. 2005. 2006. LEV. M. D. V. . 20. In: ACM SIGPLAN CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION.. Proceedings. . Hybrid transactional memory. M...67–78.n. N. LUCHANGCO. DAMRON. ACM Computing Surveys (CSUR).2. 2009. São Paulo: Pearson Prentice Hall. 2006. In: ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES AND OPERATING SYSTEMS. . p. CALDER. O. p. O. (PLDI ’09). Software Transactional Memory Should Not Be Obstruction- . KAPALKA.. SHOSHANI. COFFMAN.336–346.347–358. COLAVIN. [S. Transactional Locking II. B.VAN BIESBROUCK. DEITEL. ACM. In: ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES AND OPERATING SYSTEMS. P.. .: s. 2006. DEITEL.. l. Transaction processing: concepts and techniques. ACM. FETZER. A. (Relatório Técnico 579). [S. C. [S.]: Springer-Verlag. USA.l. . 1993. M. It’s too darn hot.6. T.. FRASER. LNCS: Springer. M. B. 2008. GUERRAOUI. W.l. Proceedings. S. [S. P. Data Centers: how to cut carbon emissions and costs. [S. 2005. RIEGEL.]: University of Cambridge. N. KAPLAN.l.. Germany. . v. .237–246. 55 FLEISCHMANN. com. KINDLER.]. Practical lock-freedom.l. . Polymorphic Contention Management. FORREST. 2001. p. 2008. . NY... POCHON. In: DISC ’05: PROCEEDINGS OF THE NINETEENTH INTERNATIONAL SYMPOSIUM ON DISTRIBUTED COMPUTING. K. [S.]: Intel Research Cambridge Tech Report.Free. n. In: ACM SIGPLAN SYMPOSIUM ON PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING. Dynamic performance tuning of wordbased software transactional memory.]: Morgan Kaufmann. HAMM. REUTER. McKinsey on Business Technology. 2006.. Businessweek. p. 2008. 2004.. New York.l.]. R. J. 2008. HERLIHY. 2005.. FELBER. GRAY. Anais. Quantitative models for reverse logistics: lecture notes in economics and mathematical systems. (PPoPP ’08). (IRCTR-06-052).. [S. J. 13.14.303–323. (ISCA ’04). AND APPLICATIONS. M. S.. In: MANAGEMENT OF ENGINEERING & TECHNOLOGY.]. J. Language support for lightweight transactions.102–.: s. N. In: ACM SIGPLAN CONFERENCE ON OBJECT-ORIENTED PROGRAMING.. USA. K. HERTZBERG. WIJAYA. In: COMPUTER ARCHITECTURE. . Anais. p. 2003. B. PEYTON-JONES. D. HARRIS. LANGUAGES. R.. p.48–60. Proceedings. T.. OLUKOTUN.: s. ACM. D.. p. DAVIS.. NY. D. . 2009... Washington. SYSTEMS.. PLESKO..n. V.. CARLSTROM. Composable memory transactions. . KOZYRAKIS.l. TARDITI. 2005. Transactional Memory Coherence and Consistency. M. IEEE Computer Society. FRASER. T. 2005. . p. [S. In: ACM SIGPLAN SYMPOSIUM ON PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING. 31. A. USA.].l. Proceedings.n. HARRIS. PORTLAND INTERNATIONAL CONFERENCE ON. Optimizing memory . K.HAMMOND. B.. H. 2009. WONG. M. . . Proceedings. K. CHEN. PRABHU. ... T. AUSEKLIS. 2003. S. (OOPSLA ’03).388–402. Sustainable IT services: assessing the impact of green computing practices. 2004. C. HARRIS..... HARMON.. L. MARLOW. New York. SHINNAR. [S. DC. 18. M. 2004. 2009.1707–1717. PICMET 2009. HERLIHY. . ACM. Proceedings. (ISCA ’93)... KAXIRAS.l.. . Some Deadlock Properties of Computer Systems. M. Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O’Reilly)). (PLDI ’06). RIGO. USA. 2006. J. MARTONOSI. Proceedings. W. ACM. p. MOIR. New York. 1993.transactions. V. Inc. In: ACM SIGPLAN CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION. [S. HOLT.]. M. . New York. 2003.. . JONES. S. R. .]: Morgan & Claypool Publishers. P. p. C. O’Reilly Media. [S. p. MOREIRA. . NY. Beautiful concurrency.289–300. 2006. In: PRINCIPLES OF DISTRIBUTED COMPUTING. LUCHANGCO. New York... MOSS. NY. Computer Architecture Techniques for PowerEfficiency. NY. F. p. Transactional memory: architectural support for lock-free data structures. USA. 2003. E. NY. p. A. N. USA. v. 1993. (PODC ’03). 2008.l. Software transactional memory for dynamic-sized data structures.14–25. CENTODUCATTE.. (Synthesis Lectures on Computer Architecture).. M. ACM.4. 2007. HERLIHY. HERLIHY.. September 1972.. . J. 2006.92–101. KLEIN. B. New York. Surv. BALDASSIN.179–196. M.385–406. S. In: OF THE 20TH ANNUAL INTERNATIONAL 56 SYMPOSIUM ON COMPUTER ARCHITECTURE. USA. Proceedings.. . ACM Comput. SCHERER III. Memória Transacional em Hardware para Sistemas Embarcados Multiprocessados Conectados por Redes-em-Chip. Green computing. 2010. C. 2008. J. 2009. ACM..209–220. . USA. 16. p. SP. .S. [S. 2009. USA.11–13. Commun. v. M.l. ACM. NY. HUGHES. . Porto Alegre. NGUYEN. Experimentos com Gerenciamento de Contenção em uma Memória Transacional com Suporte em Software. KUMAR. (PPoPP ’06). AZEVEDO. (ISLPED ’10). S. KURP. Brasil.44– 51.ed. NY. KUNDU.. S. 1st.431–436. New York. 2006. In: ACM SIGPLAN SYMPOSIUM ON PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING.. p. L. Proceedings. A. CHU. In: ACM/IEEE INTERNATIONAL SYMPOSIUM ON LOW POWER ELECTRONICS AND DESIGN. KUNZ. Brasil. P. USA.]: IBM Press. 2006. New York. P. New York. STM versus lock-based systems: an energy consumption perspective. RS. J... ACM. KRONBAUER. p. R. São Paulo. . Dissertação (Mestrado em Ciência da Computação) — Universidade Federal do Rio Grande do Sul. NY. Oct.. F. 2010.51. . RIGO. Hybrid transactional memory. Proceedings. LAMB. 2010. Anais do X Simpósio em Sistemas Computacionais WSCAD-SSC. The Greening of IT: how companies can make a difference for the environment.. p. ]. Cracow. .. CA. V. J. USA. Cycle-accurate power analysis for multiprocessor systems-on-a-chip. M.n. July 1993. A. M.. 2005. Poland. HÅLLBERG. M... 19..354–368. C. LOGHI. ESKILSON.35..26. Adaptive Software Transactional Memory. N. G. (GLSVLSI ’04). In: ACM GREAT LAKES SYMPOSIUM ON VLSI. In: FIRST ACM SIGPLAN WORKSHOP ON LANGUAGES... Los Alamitos. EISENSTAT. S. 57 MARATHE. P.. D. ACM. Scherer III. [S. M. L. J. p.. FORSGREN. v. Proceedings. WERNER. p..50–58. . J. 2004. III. SCOTT. 2004. W.. An Investigation of the Therac25 Accidents. SCOTT. In: INTERNATIONAL SYMPOSIUM ON DISTRIBUTED COMPUTING. N. CA. NY. L. USA.LEVESON. 14. Earlier but expanded version available as TR 868. D. ... TURNER. . p. New York. Computer. F. February 2002. J.. M. Los Alamitos. Simics: a full system simulation platform. N. MOESTEDT. v. HöGBERG. C.l. p. 2005. MARATHE. BENINI. LARSSON.410–406.: s. USA. G. Computer. .. MAGNUSSON. SPEAR... ACHARYA. V. W. Lowering the overhead of nonblocking software transactional memory. A. S..18–41. CHRISTENSSON. S. L.. B. PONCINO.. F. Proceedings. M. HERIOT. May2005. University of Rochester Computer Science Dept.. HILL. E. A. .503–507... BRONSON. C.44. HERLIHY. I.. M. M.n. New York. AND HARDWARE SUPPORT FOR TRANSACTIONAL COMPUTING.8.. In: COMPUTER ARCHITECTURE. An effective hybrid transactional memory system with strong isolation guarantees.69–80.. ACM.]. p. International Journal of Computer Science Issues.. MORAVAN... 2006. Anais.n. K. J. A Resolution for Shared Memory Conflict in Multiprocessor System-on-a-Chip. J. MICHAEL. T. In: Proceedings of the 12th International Symposium on High-Performance Computer Architecture. J. Syst. MCKENNEY. p.. CASPER. p. Proceedings.93– 101. Rev. MITTAL. In: LOW POWER .]. R.. Why the grass may not be greener on the other side: a comparison of locking vs. MOORE. v.. IJCSI. BOBBA. M. 2007. A. MCDONALD. 2006. TRIPLETT.254–265.. NITIN. transactional memory. J. Energy reduction in multiprocessor systems using ELECTRONICS AND transactional memory. New York. p. C. KOZYRAKIS.]. E. NY. USA.l. [S.: s.. 2007. July 2011.. v. August 2010. 2006. P. D. S.l. LogTM: log-based transactional memory. M. D. . SIGOPS Oper.COMPILERS. C.. 34.: s.. K. TRAUTMANN. . NY. BAHAR. [S.. OLUKOTUN. [S. N.. CHUNG. . J.l. J. MINH. M. WOOD. MORESHET. (ISCA ’07). USA. WALPOLE.. M. p. CARISSIMI. d. April. . A. XXX Congresso da Sociedade Brasileira de Computação. NY. M. p.. USA. In: COMPUTER ARCHITECTURE. MÓR. In 4th Workshop on Memory Performance Issues.. Sistemas Operacionais. 2006. RAJWAR. New York. O. BAHAR. USA. TOSCANI.].24–33. Porto Alegre: Editora Bookman. held in conjunction with the International Symposium on High-Performance Computer Architecture. 58 POULSEN. Virtualizing Transactional Memory.. A.. Proceedings.. M. S. 32. D. . O. v. J. Tracking the blackout bug. 2008. P. USA. 2010. MURUGESAN. HERLIHY. D. 3. MAILARD.346–360. IT Professional. HOFMANN.. M.l. H. LAI. January 2008. (ISCA ’05). de.. R. LIMA. HERLIHY.. (ISLPED ’05).l. Security Focus. [S. S. K. IEEE Computer Society.10. I. S. V. S. S. ALVES. 2004. Proceedings.331– 334. . p.]. 2005. [S.. p. E. NJ. N.]. Energy-aware microprocessor synchronization: transactional memory vs. R. locks. F. T... Washington..l. Eficiência Energética em Computação de Alto Desempenho: uma abordagem em arquitetura e programação para green computing. OLIVEIRA. B.ed. . 2005.. K. DC. S. PORTER.. 2005. Piscataway. A.494–505. Harnessing Green IT: principles and practices. E. MORESHET. J. CSBC. . [S. RAMADAN..DESIGN. NAVAUX. 2005. ACM. S. 2005. C. R. K. ROSSBACH. . .. 2007. P. 2006. McRT-STM: a high performance software transactional memory system for a multi-core runtime.....]: In Proceedings of the 19th International Symposium on Computer Architecture and High Performance Computing. ACM. WITCHEL. B. MINH. p. SAHA. ADL-TABATABAI.. ADL-TABATABAI. 2006. RAMANATHAN. In: IN PROC. USA. JACOBSON. 2007. NY. Architectural Support for Software Transactional Memory. B. Memórias Transacionais: uma nova alternativa para programação concorrente.-R. IEEE Computer Society.BHANDARI. L. Proceedings. Platform 2015: intel processor and platform evolution for the next decade. HERTZBERG. 2007. . Q. 39.. RIGO. SAHA. . ACM Press. p. Proceedings.. Washington. R. HUDSON. [S. ON PRINCIPLES AND PRACTICE OF PARALLEL PROGRAMMING. A.l. Anais. OF THE 11TH ACM SYMP. S. CENTODUCATTE. 34.l. In: ANNUAL IEEE/ACM INTERNATIONAL SYMPOSIUM ON MICROARCHITECTURE. A. p. A. A. 2006.. B.. In: COMPUTER ARCHITECTURE.185–196. BALDASSIN. . (ISCA ’07). USA. . C.]. THOMAS.92–103.187–197. (MICRO 39).. E. T. MetaTM/TxLinux: transactional memory for an operating system. [S. C. reza. 2005. DC. New York. 2006. . Intel Corporation White Paper. V. . p. TOUITOU. 2010. F. A. Fundamentos de Sistemas Operacionais. POONGODI. NY.. NY. USA. S. H. L..ed. 2007. . 2008. Porto Alegre: Editora Bookman. A. DWARKADAS. S. p. A. 1995. Proceedings. In: ANNUAL INTERNATIONAL SYMPOSIUM ON COMPUTER ARCHITECTURE. USA. WOODHULL. DWARKADAS. IEEE Computer Society. Proceedings. DC. 1995. S. SHRIRAMAN.. SPEAR.. USA.131–135. SCOTT. 59 .. Sistemas Operacionais: projeto e implementação. New York.. ACM. GALVIN. GAGNE. 3. 2008. . In: COMPUTER ARCHITECTURE. HOSSAIN.]. M. V.104–115. A. D. S.ed. . . M.. A. .. New York. J. Software transactional memory.SHARAVANAN.. Washington. SCOTT. Journal of Mathematics and Technology.. 35.l... (PODC ’95). 2007. SILBERSCHATZ. Rio de Janeiro: Editora LTC. L. (ISCA ’08).204–213. An integrated hardware-software approach to flexible transactional memory. 34. . TANENBAUM. ACM. N. p. p. 6. P. B. 2008. Towards Green Computing: energy efficient data centers. MARATHE. SHAVIT. G. M. A. In: ACM SYMPOSIUM ON PRINCIPLES OF DISTRIBUTED COMPUTING.. Proceedings. KUMAR. D. SHRIRAMAN. Flexible Decoupled Transactional Memory Support..139–150. 2009. S. (ISCA ’07). [S. .].UHRIG.. O. p. Energy Management for Embedded Multithreaded Processors with Integrated EDF Scheduling. WANG. WILNER. E. C. 1995. JOUPPI. [S. White Paper. MALIK. . WOO. 2002. H.294–305. Systems Aspects in Organic and Pervasive Computing-ARCS 2005. . TORRIE. . WILTON. 2005. USA.31. New York..]. P. In: ACM/IEEE INTERNATIONAL SYMPOSIUM ON MICROARCHITECTURE. PEH.4–5. WECHSLER. X. SINGH. Los Alamitos.-S. M. .. [S. L. J.l.-S. (ISCA ’95). v. . N. p. ZHU. Inside Intel Core Microarchitecture. 35.n. Orion: a powerperformance simulator for interconnection networks. Proceedings.l. [S. p. 2002.24–36. The SPLASH-2 programs: characterization and methodological considerations.1–17.. 1995. p. Anais. P. 1997. S. .]. [S. J... ACM. In: KEYNOTE AT THE 18TH IEEE REAL-TIME SYSTEMS SYMPOSIUM (RTSS’97). D.]. 2006.. S. UNGERER. (MICRO 35).l.677– 688. S. Proceedings. 22. IEEE Computer Society Press. In: COMPUTER ARCHITECTURE. CA.. A. 1997... CACTI: an enhanced cache access and cycle time model.l. 1996. E. IEEE Journal of Solid-State Circuits. p. S.. T. Setting New Standards for Energy-Efficient Performance. OHARA.: s. DEZ. USA. NY. Vx-files: what really happened on mars. GUPTA.