BR112016021217B1 - Aumento de protocolo de coerência para indicar o estado da transação - Google Patents

Abstract

AUMENTO DE PROTOCOLO DE COERÊNCIA PARA INDICAR O ESTADO DA TRANSAÇÃO. Concretizações referem-se à implementação de um protocolo de coerência. Um aspecto inclui o envio de um pedido de dados a um processador remoto e receber, por um processador, uma resposta do processador remoto. A resposta tem um estado de transação de uma transação remota no processador remoto. O processador adiciona o estado de transação da transação remota no processador remoto em uma tabela de rastreamento de interferência de transação local.

Description

Antecedentes

[0001] A presente invenção refere-se, de um modo geral, a protocolos de solicitação e resposta e, mais especificamente, ao aumento do protocolo de coerência para indicar o estado da transação.

[0002] O número de núcleos de unidades de processamento central (Central Processing Unit - CPU) em um chip e o número de núcleos de CPU conectados a uma memória compartilhada continuam a crescer de forma significativa para dar suporte à crescente demanda por capacidade de carga de trabalho. O número crescente de CPUs que cooperam para processar as mesmas cargas de trabalho impõe um encargo significativo na escalabilidade de software; por exemplo, filas compartilhadas ou estruturas de dados protegidas por semáforos tradicionais se tornam pontos quentes e levam a curvas sublineares de escalonamento de n formas. Tradicionalmente, isto tem sido combatido através da implementação de um bloqueio mais refinado no software e com interconexões de menor latência/maior largura de banda em hardware. A implementação de bloqueio mais refinado para melhorar a escalabilidade de software pode ser muito complicada e propensa a erros e, nas frequências de CPU de hoje, as latências de interconexões de hardware são limitadas pela dimensão física dos chips e sistemas e pela velocidade da luz .

[0003] Foi introduzida a memória transacional em hardware (Hardware Transactional Memory - HTM ou, nesta discussão, simplesmente TM), em que um grupo de instruções - denominado uma transação - opera de uma maneira atômica sobre uma estrutura de dados na memória, conforme visto por outras unidades de processamento centrais (CPUs) e o subsistema I/O (a operação atômica é também conhecida como bloco concorrente ou serializada em outra literatura). A transação é executada, de forma otimista, sem a obtenção de um bloqueio, mas pode ser necessário abortar e repetir a execução da transação se uma operação, da transação em execução, em um local da memória entra em conflito com a operação anterior no mesmo local de memória. Anteriormente, implementações de memória transacional em software foram propostas para dar suporte à Memória Transacional (Transactional Memory - TM) em software.

Sumário

[0004] As concretizações incluem um método, um sistema e um produto de programa de computador para implementar um protocolo de coerência. Uma solicitação de dados é enviada para um processador remoto. Um processador recebe uma resposta a partir do processador remoto e a resposta tem um estado de transação de uma transação remota sobre o processador remoto. O processador adiciona o estado de transação da transação remota sobre o processador remoto em uma tabela de rastreio de interferência de transação local.

Breve Descrição Das Várias Vistas Dos Desenhos

[0005] O assunto o qual é considerado como concretizações é particularmente destacado e distintamente reivindicado nas reivindicações ao término do relatório descritivo. As características anteriores e outras e vantagens das concretizações são evidentes a partir da descrição detalhada a seguir, tomada em conjunto com os desenhos anexos, nos quais: a Figura 1 representa um diagrama de blocos esquemático de um ambiente de memória transacional em múltiplos processadores (CPUs)/núcleos exemplificativo de acordo com uma concretização; a Figura 2 representa um diagrama de blocos esquemático que ilustra um processador transacional de acordo com uma concretização; a Figura 3 representa um diagrama de blocos esquemático de componentes exemplificativos de um processador transacional (CPU) mostrado nas Figuras 1 e 2 de acordo com uma concretização; a Figura 4 representa um diagrama de blocos esquemático de um sistema de computador que tem componentes como os sistemas de multiprocessador mostrado nas Figuras 1-3 para permitir solicitações e respostas em um ambiente de memória transacional em hardware de acordo com uma concretização; a Figura 5 representa uma solicitação de protocolo e resposta exemplificativas de acordo com uma concretização; a Figura 6 representa um solicitação de protocolo exemplificativa de acordo com uma concretização; a Figura 7 representa um fluxograma de geração de solicitação de protocolo por um processador que faz uma solicitação de dados de acordo com uma concretização; a Figura 8 representa um fluxograma de gerenciamento de solicitações pelo processador receptor/remoto que recebe a solicitação e envia uma resposta de acordo com uma concretização; a Figura 9 representa um fluxograma que ilustra o gerenciamento de transações por um processador de acordo com uma concretização; a Figura 10 representa a solicitação de protocolo e uma nova resposta de protocolo de acordo com uma concretização; a Figura 11 representa a solicitação de gravação de protocolo e uma nova resposta de acordo com uma concretização; a Figura 12 representa um fluxograma que ilustra o gerenciamento de solicitação de coerência pelo processador receptor/remoto que recebe a solicitação de acordo com uma concretização; a Figura 13 representa um fluxograma que ilustra a origem de solicitações de protocolo e processamento pelo processador solicitante de acordo com uma concretização; a Figura 14 representa um fluxograma que ilustra o gerenciamento de transações por um processador de acordo com uma concretização; a Figura 15 representa um fluxograma que ilustra como o processador responde à indicação de interferência em uma tabela de armazenamento de rastreio de interferência de transação local de acordo com uma concretização; a Figura 16 representa um fluxograma que ilustra como o processador responde à indicação de interferência na tabela de armazenamento de rastreio de interferência de transação local de acordo com uma concretização; a Figura 17 representa um método para gerenciamento de protocolo de coerência de acordo com uma concretização; e a Figura 18 representa um meio legível em computador de acordo com uma concretização.

Descrição Detalhada

[0006] Sistemas de multiprocessador usam protocolos de coerência para manter a consistência entre todos os caches em um sistema de memória compartilhada distribuída. Quando uma solicitação de dados a partir de um determinado cache é feita, o cache edita os dados e atualiza seu estado de modo que ele não tenha mais os dados ou de modo que os dados não são exclusivamente retidos. Se um processador está em uma execução transacional e são solicitados dados provenientes de seu cache que são uma parte da transação, o processador abortará a transação e enviará os dados.

[0007] Nenhuma informação é fornecida se uma solicitação causou o cancelamento de outra transação. Em alguns casos, será desejável notificar o solicitante original se uma solicitação teve um impacto sobre outra operação para fornecer um feedback e permitir que aquele que originou a solicitação adapte sua execução, por exemplo, para detectar situações de "livelock" e abordar outras situações que degradam o desempenho.

[0008] De acordo com a concretização, o protocolo de coerência é estendido para incluir a informação adicional sobre o estado da transação. Quando um processador está em execução transacional, uma solicitação de coerência pode fazer com que sua execução seja abortada, por exemplo, porque os dados são parte do conjunto de leitura ou gravação da transação e é detectado um conflito. A solicitação de protocolo de coerência é estendida com informações adicionais de que ele (processador que recebe a solicitação de coerência) abortou uma transação durante a execução transacional de acordo com concretizações.

[0009] O "Power ISA™ Versão 2.07 publicado em 22 de maio de 2013 da IBM® e incorporado por referência na íntegra ensina uma arquitetura de conjunto de instruções (Instruction Set Architecture - ISA) Reduced Instruction Set Computer (RISC)" exemplificativa. Além disso, "z/Architecture Principies of Operation" SA22-7832-09 (agosto de 2012) da IBM® e incorporado por referência na íntegra ensina uma arquitetura de conjunto de instruções CISC (Complex Instruction Set Computer")) exemplificativa.

[0010] Historicamente, um sistema de computador ou processador tinha apenas um único processador (também conhecido como unidade de processamento ou unidade de processamento central). O processador incluía uma unidade de processamento de instruções (Instruction Processing Unit - IPU), uma unidade de ramificação, uma unidade de controle de memória e assim por diante. Tais processadores eram capazes de executar uma única linha de instruções ("thread") de um programa ao mesmo tempo. Foram desenvolvidos sistemas operacionais que poderiam compartilhar no tempo um processador ao despachar um programa a ser executado no processador por um período de tempo e depois despachar outro programa a ser executado no processador por um novo período de tempo. À medida que a tecnologia evoluiu, caches de subsistema de memória eram, muitas vezes, adicionados ao processador, bem como tradução de endereço dinâmica complexa, incluindo memórias associativas (Translation Lookaside Buffers - TLBs). A própria IPU era frequentemente referida como um processador. À medida que a tecnologia continuou a evoluir, um processador inteiro pôde ser acondicionado em um único chip ou matriz semicondutora, tal processador era referido como um microprocessador. Então, foram desenvolvidos processadores que incorporaram múltiplas IPUs, tais processadores eram, muitas vezes, referidos como multiprocessadores. Cada um de tais processadores de um sistema de computador multiprocessador (processador) pode incluir caches, interfaces de memória, barramentos de sistema, mecanismos de tradução de endereços individuais ou compartilhados e assim por diante. Os emuladores de máquina virtual e arquitetura de conjunto de instruções (ISA) adicionaram uma camada de software a um processador, que forneceram à máquina virtual vários "processadores virtuais" (anteriormente conhecidos como processadores) pelo uso de fatias de tempo de uma única IPU em um único processador em hardware. À medida que a tecnologia evoluiu mais, foram desenvolvidos processadores com múltiplas linhas de instruções, viabilizando um único processador em hardware que tinha uma única IPU para conferir uma capacidade de executar simultaneamente linhas de instruções de diferentes programas, assim, cada linha de instruções de um processador de múltiplas linhas de instruções aparecia para o sistema operacional como um processador. À medida que a tecnologia evoluiu ainda mais, foi possível colocar vários processadores (cada um tendo uma IPU) em um único chip ou matriz semicondutora. Estes processadores eram referidos como núcleos de processador ou apenas núcleos. Assim, os termos tais como processador, unidade de processamento central, unidade de processamento, microprocessador, núcleo, núcleo processador, processador de linha de instruções, linha de instruções, por exemplo são, muitas vezes, usados alternadamente. Aspectos das concretizações aqui podem ser praticados por qualquer um ou todos os processadores, incluindo aqueles mostrados acima, sem se afastar dos ensinamentos apresentados aqui. Onde o termo "linha de instruções" ou "processador de linha de instruções" é usado aqui, espera-se que uma vantagem particular da concretização possa ter ocorrido em uma implementação de linha de instruções de processador. Execução de Transações em Concretizações com Base em Intel®

[0011] Em "Intel® Architecture Instruction Set Extensions Programming Reference" 319433-012A, fevereiro de 2012, incorporado aqui por referência na íntegra, o Capítulo 8 ensina, em parte, que aplicativos com múltiplas linhas de instruções podem tirar proveito dos números crescentes de núcleos de CPU para obter um desempenho mais elevado. No entanto, a gravação de aplicativos com múltiplas linhas de instruções requer programadores para entender e levar em conta o compartilhamento de dados entre as várias linhas de instruções. O acesso a dados compartilhados requer, tipicamente, mecanismos de sincronização. Estes mecanismos de sincronização são usados para garantir que várias linhas de instruções atualizem dados compartilhados por meio de operações de serialização que são aplicadas aos dados compartilhados, muitas vezes através do uso de uma seção crítica que é protegida por um bloqueio. Uma vez que a serialização limita a concorrência, os programadores tentam limitar a sobrecarga em virtude de sincronização.

[0012] Intel® Transactional Synchronization Extensions (Intel ® TSX) permite que um processador determine dinamicamente se linhas de instruções precisam ser serializadas através seções críticas protegidas com bloqueio e realize esta serialização somente quando necessário. Isto permite que o processador exponha e explore a concorrência que está oculta em um aplicativo em virtude de sincronização dinâmica desnecessária.

[0013] Com Intel TSX, regiões de código especificadas pelo programadas (também referidas como "regiões transacionais" ou apenas "transações") são executadas de forma transacional. Se a execução transacional for concluída com êxito, então, todas as operações de memória executadas dentro da região transacional parecerão ter ocorrido instantaneamente quando vistas a partir de outros processadores. Um processador torna as operações na memória da transação executada, realizada dentro da região transacional, visíveis para outros processadores somente quando uma confirmação com sucesso ocorre, ou seja, quando a execução da transação é concluída com êxito.

[0014] Este processo é, muitas vezes, referido como uma confirmação atômica.

[0015] O Intel TSX fornece duas interfaces de software para especificar regiões de código para execução transacional. Omissão de bloqueio em Hardware (Hardware Lock Elision - HLE) é uma extensão do conjunto de instruções compatível legado (compreendendo os prefixos XACQUIRE e XRELEASE) para especificar regiões transacionais. A Memória Transacional Restrita (Restricted Transactional Memory - RTM) é uma nova interface de conjunto de instruções (compreendendo as instruções XBEGIN, XEND e XABORT) para que os programadores definam regiões transacionais de uma maneira mais flexível do que aquela possível com HLE. HLE é para programadores que preferem a compatibilidade com versões anteriores do modelo de programação por exclusão mútua convencional e gostariam de executar software com HLE habilitado em hardware legado, mas também gostariam de tirar proveito das novas capacidades de omissão de bloqueio em hardware com suporte para HLE. RTM é para programadores que preferem uma interface flexível para execução transacional em hardware. Além disso, o Intel TSX também fornece uma instrução XTEST. Esta instrução permite que o software consulte se o processador lógico em execução de forma transacional em uma região transacional identificada por HLE ou RTM.

[0016] Uma vez que uma execução transacional bem- sucedida garante uma confirmação atômica, o processador executa a região de código de forma otimista sem sincronização explícita. Se a sincronização era desnecessária para esta execução específica, a execução pode ser confirmada sem qualquer serialização entre linhas de instruções. Se o processador não puder realizar a confirmação atômica, a execução otimista falhará. Quando isto acontece, o processador reverterá a execução, um processo referido como um aborto transacional. Em um aborto transacional, o processador descartará todas as alterações realizadas na região da memória usada pela transação, restaurará o estado de arquitetura para aparecer como se a execução otimista nunca tivesse ocorrido e continuará a execução de forma não transacional.

[0017] Um processador pode executar um aborto transacional por inúmeras razões. Uma razão primária para abortar uma transação é em virtude de conflitos de acesso à memória entre o processador lógico que faz a execução transacional e outro processador lógico. Tais acessos à memória conflitantes podem impedir uma execução transacional bem sucedida. Endereços de memória lidos a partir de dentro de uma região transacional constituem o conjunto de leitura da região transacional e endereços gravados dentro da região transacional constituem o conjunto de gravação da região transacional. O Intel TSX mantém os conjuntos de leitura e conjuntos de endereços na granularidade de uma linha de cache. Um acesso à memória conflitante ocorre se outro processador lógico lê uma localização que é parte do conjunto de gravação da região de transação ou grava uma localização que é uma parte do conjunto de leitura ou gravação da região transacional. Um acesso conflitante significa, tipicamente, que serialização é necessária para esta região de código. Uma vez que o Intel TSX detecta conflitos de dados na granularidade de uma linha de cache, localizações de dados não relacionados colocados na mesma linha de cache serão detectadas como conflitos que resultam em aborto transacional. Abortos transacionais também podem ocorrer em virtude de recursos transacionais limitados. Por exemplo, a quantidade de dados acessados na região pode exceder uma capacidade de implementação específica. Além disso, algumas instruções e eventos do sistema podem causar interrupções transacionais. Abortos transacionais frequentes resultam em ciclos desperdiçados e maior ineficiência.

Omissão de bloqueio em Hardware

[0018] A omissão de bloqueio em hardware (HLE) constitui uma interface de conjunto de instruções compatível legado para que os programadores usem a execução transacional. HLE fornece duas novas sugestões de prefixo de instrução: XACQUIRE e XRELEASE.

[0019] Com a HLE, um programador adiciona o prefixo XACQUIRE na frente da instrução que é usada para adquirir o bloqueio que está protegendo a seção crítica. O processador trata o prefixo como uma sugestão para eliminar a gravação associada à operação de aquisição de bloqueio. Mesmo que a aquisição de bloqueio tenha uma operação de gravação associada ao bloqueio, o processador não adiciona o endereço do bloqueio ao conjunto de gravação da região transacional nem emite quaisquer solicitações de gravação para o bloqueio. Em vez disso, o endereço do bloqueio é adicionado ao conjunto de leitura. O processador lógico entra em execução transacional. Se o bloqueio estava disponível antes da instrução de prefixo XACQUIRE, todos os outros processadores continuarão a ver o bloqueio como disponível posteriormente. Uma vez que o processador lógico que está em execução transacional não adicionou o endereço do bloqueio ao conjunto de gravação nem realizou operações de gravação externamente visíveis para o bloqueio, outros processadores lógicos podem ler o bloqueio sem causar um conflito de dados. Isto permite que outros processadores lógicos também entrem e executem concorrentemente a seção crítica protegida pelo bloqueio. O processador detecta automaticamente quaisquer conflitos de dados que ocorrem durante a execução transacional e executará um aborto transacional, se necessário.

[0020] Mesmo que o processador que faz a omissão não tenha realizado quaisquer operações externas de gravação para o bloqueio, o hardware garante a ordem de operações do programa sobre o bloqueio. Se o processador que faz a omissão em si lê o valor do bloqueio na seção crítica, ele aparecerá como se o processador tivesse adquirido o bloqueio, ou seja, a leitura retornará o valor não omitido. Este comportamento permite que uma execução HLE seja funcionalmente equivalente a uma execução sem os prefixos HLE.

[0021] Um prefixo XRELEASE pode ser adicionado na frente de uma instrução que é usada para liberar o bloqueio que protege uma seção crítica. A liberação do bloqueio envolve uma gravação para o bloqueio. Se a instrução é para restaurar o valor do bloqueio para o valor que o bloqueio tinha antes da operação de aquisição de bloqueio de prefixo XACQUIRE sobre o mesmo bloqueio, então, o processador omite a solicitação de gravação externa associada à liberação do bloqueio e não adiciona o endereço do bloqueio ao conjunto de gravação. O processador, então, tenta confirmar a execução transacional.

[0022] Com HLE, se várias linhas de instruções executam seções críticas protegidas pelo mesmo bloqueio, mas elas não executam quaisquer operações conflitantes sobre cada um dos outros dados, então, as linhas de instruções podem ser executadas simultaneamente e sem serialização. Mesmo que o software use as operações de aquisição de bloqueio sobre um bloqueio em comum, o hardware reconhece isto, omite o bloqueio e executa seções críticas sobre as duas linhas de instruções sem a necessidade de qualquer comunicação através do bloqueio - se tal comunicação era dinamicamente desnecessária.

[0023] Se o processador não é capaz de executar a região de forma transacional, então, o processador executará a região de forma não transacional e sem omissão. O software habilitado com HLE tem as mesmas garantias de progresso anteriores que a execução subjacente com base em bloqueio não HLE. Para a execução bem sucedida de HLE, o bloqueio e o código da seção crítica devem seguir determinadas diretrizes. Estas diretrizes afetam não apenas o desempenho; e o não cumprimento destas diretrizes não resultará em uma falha funcional. O hardware sem suporte à HLE ignorará as sugestões de prefixo XACQUIRE e XRELEASE e não executará qualquer omissão, uma vez que estes prefixos correspondem aos prefixos REPNE/REPE IA-32 os quais são ignorados nas instruções onde XACQUIRE e XRELEASE são válidos. De forma importante, a HLE é compatível com o modelo de programação com base em bloqueio existente. O uso inadequado de sugestões não causará erros funcionais, embora possa expor erros latentes já no código.

[0024] A memória transacional restrita (RTM) constitui uma interface de software flexível para execução transacional. A RTM oferece três novas instruções - XBEGIN, XEND e XABORT - para que os programadores iniciem, validem e abortem uma execução transacional.

[0025] O programador usa a instrução XBEGIN para especificar o início de uma região de código transacional e a instrução XEND para especificar o fim da região de código transacional. Se a região de RTM não pôde ser executada com sucesso de forma transacional, então, a instrução XBEGIN assume um operando que permite um desvio relativo para a revogação do endereço de instrução.

[0026] Um processador pode abortar a execução transacional RTM por muitas razões. Em muitos casos, o hardware detecta automaticamente as condições de aborto transacional e reinicia a execução de instruções a partir da revogação do endereço de instrução com estado de arquitetura que corresponde àquele presente no início da instrução XBEGIN e o registro EAX atualizado para descrever o estado de abortar.

[0027] A instrução XABORT permite que os programadores abortem a execução de uma região RTM explicitamente. A instrução XABORT assume um argumento imediato de 8 bits que é carregado no registro EAX e, portanto, estará disponível para o software após um aborto de RTM. Instruções RTM não têm qualquer localização na memória de dados associada às mesmas. Embora o hardware não ofereça garantias quanto ao fato se uma região RTM sempre confirmará com sucesso de forma transacional, espera-se que a maioria das transações que seguem as diretrizes recomendadas sejam confirmadas com sucesso de forma transacional. No entanto, os programadores devem sempre fornecer uma sequência de código alternativa no percurso de revogação para garantir o progresso futuro.

[0028] Isto pode ser tão simples quanto adquirir um bloqueio e executar a região de código especificada de forma não transacional. Além disso, uma transação que é sempre abortada em uma determinada implementação pode ser concluída de forma transacional quando de uma implementação futura. Portanto, os programadores devem garantir que os percursos de código para a região transacional e a sequência de código alternativa sejam testados funcionalmente.

Detecção de Suporte à HLE

[0029] Um processador dá suporte à execução de HLE se CPUID.07H.EBX.HLE [bit 4] = 1. No entanto, um aplicativo pode usar os prefixos de HLE (XACQUIRE e XRELEASE) sem verificar se o processador dá suporte à HLE. Processadores sem suporte à HLE ignoram estes prefixos e executarão o código sem entrar em execução transacional.

Detecção de Suporte à RTM

[0030] Um processador dá suporte à execução RTM se CPUID.07H.EBX.RTM [bit 11] = 1. Um aplicativo deve verificar se o processador dá suporte à RTM antes de usar as instruções RTM (XBEGIN, XEND, XABORT). Estas instruções gerarão uma exceção #UD quando usadas em um processador que não dá suporte à RTM.

Detecção da Instrução XTEST

[0031] Um processador dá suporte à instrução XTEST se ele dá suporte à HLE ou RTM. Um aplicativo deve verificar qualquer um destes sinalizadores de recurso antes de usar a instrução XTEST. Esta instrução gerará uma exceção #UD quando usada em um processador que não dá suporte à HLE ou RTM.

Consulta do Estado de Execução Transacional

[0032] A instrução XTEST pode ser usada para determinar o estado transacional de uma região transacional especificada por HLE ou RTM. Observe que, embora os prefixos de HLE sejam ignorados em processadores que não dão suporte à HLE, a instrução XTEST gerará uma exceção #UD quando usada em processadores que não dão suporte à HLE ou RTM.

Requisitos para Bloqueios de HLE

[0033] Para a execução de HLE com confirmação transacional bem sucedida, o bloqueio deve satisfazer determinadas propriedades e o acesso ao bloqueio deve seguir determinadas diretrizes.

[0034] Uma instrução de prefixo XRELEASE deve restaurar o valor do bloqueio omitido para o valor que ele tinha antes da aquisição de bloqueio. Isto permite que o hardware omita com segurança os bloqueios ao não adicioná- los ao conjunto de gravação. O tamanho dos dados e endereço de dados da instrução de liberação de bloqueio (de prefixo XRELEASE) deve corresponder àquele da aquisição de bloqueio (de prefixo XACQUIRE) e o bloqueio não deve cruzar um limite de linha de cache.

[0035] O software não deve gravar o bloqueio omitido dentro de uma região HLE transacional com qualquer outra instrução que não uma instrução de prefixo XRELEASE, caso contrário, tal gravação pode causar um aborto transacional. Além disso, bloqueios recursivos (onde um linha de instruções adquire o mesmo bloqueio várias vezes sem primeiro liberar o bloqueio) também podem causar um aborto transacional. Observe que o software pode observar o resultado da aquisição de bloqueio omitido dentro da seção crítica. Tal operação de leitura retornará o valor da gravação para o bloqueio.

[0036] O processador detecta automaticamente violações nestas diretrizes e muda com segurança para uma execução não transacional sem omissão. Uma vez que o Intel TSX detecta conflitos na granularidade de uma linha de cache, gravações em dados colocados sobre a mesma linha de cache que o bloqueio omitido podem ser detectadas como conflitos de dados por outros processadores lógicos que omitem o mesmo bloqueio.

Agrupamento Transacional

[0037] Tanto HLE quanto RTM dão suporte a regiões transacionais agrupadas. No entanto, um aborto transacional restaura o estado para a operação que iniciou a execução transacional: a instrução elegível HLE de prefixo XACQUIRE mais externa ou a instrução XBEGIN mais externa. O processador trata todas as transações agrupadas como uma transação.

Agrupamento e Omissão em HLE

[0038] Os programadores podem agrupas as regiões de HLE até uma profundidade específica de implementação de MAX HLE NEST COUNT. Cada processador lógico rastreia a contagem de agrupamento internamente, mas esta contagem não está disponível para o software. Uma instrução HLE elegível de prefixo XACQUIRE incrementa a contagem de agrupamento e uma instrução HLE elegível de prefixo XRELEASE a diminui. O processador lógico entra em execução transacional quando a contagem de agrupamento vai de zero a um. O processador lógico tenta confirmar apenas quando a contagem de agrupamento se torna zero. Um aborto transacional pode ocorrer se a contagem de agrupamento excede MAX HLE NEST COUNT.

[0039] Além de dar suporte a regiões de HLE agrupadas, o processador também pode omitir múltiplos bloqueios agrupados. O processador rastreia um bloqueio para omissão começando com a instrução HLE elegível de prefixo XACQUIRE para este bloqueio e terminando com a instrução HLE elegível de prefixo XRELEASE para este mesmo bloqueio. O processador pode, a qualquer momento, rastrear até um número MAX HLE ELIDED LOCKS de bloqueios. Por exemplo, se o aplicativo suporta um valor MAX HLE ELIDED LOCKS de dois e se o programador agrupa três seções críticas de HLE identificadas (através de realização de instruções HLE elegíveis de prefixo XACQUIRE sobre três bloqueios distintos sem executar uma instrução elegível HLE de prefixo XRELEASE interveniente em qualquer um dos bloqueios), então, os dois primeiros bloqueios serão omitidos, mas o terceiro não será omitido (mas será adicionado ao conjunto de gravação da transação). No entanto, a execução ainda continuará sendo transacional. Uma vez que uma XRELEASE para um dos dois bloqueios omitidos é encontrada, um bloqueio subsequente adquirido através da instrução HLE elegível de prefixo XACQUIRE será omitido.

[0040] O processador tenta confirmar a execução HLE quando todos os pares XACQUIRE e XRELEASE omitidos tenham sido combinados, a contagem de agrupamento vai para zero e os bloqueios têm requisitos satisfeitos. Se a execução não pode confirmar atomicamente, então, a execução muda para uma execução não transacional sem omissão como se a primeira instrução não tivesse um prefixo XACQUIRE.

Agrupamento de RTM

[0041] Os programadores podem agrupar regiões de RTM até uma implementação específica MAX RTM NEST COUNT. O processador lógico rastreia a contagem de agrupamento internamente, mas esta contagem não está disponível para o software. Uma instrução XBEGIN incrementa a contagem de agrupamento e uma instrução XEND diminui a contagem de agrupamento. O processador lógico tenta confirmar somente se a contagem de agrupamento for zero. Um aborto transacional ocorre se a contagem de agrupamento excede MAX _RTM_NEST_COUNT.

Agrupamento de HLE e RTM

[0042] HLE e RTM constituem duas interfaces de software alternativas a uma capacidade de execução transacional em comum. O comportamento de processamento transacional é específico para a implementação quando HLE e RTM são agrupadas juntos, por exemplo, HLE está dentro da RTM ou RTM está dentro da HLE. No entanto, em todos os casos, a implementação manterá semântica de HLE e RTM.

[0043] Uma implementação pode escolher ignorar sugestões de HLE quando usada dentro de regiões de RTM e pode causar um aborto transacional quando as instruções RTM são usadas dentro de regiões de HLE. No último caso, a transição de execução transacional para não transacional ocorre sem problemas, uma vez que o processador executará novamente a região de HLE sem realmente fazer a omissão e, então, executar as instruções RTM.

Definição do Estado de Abortar

[0044] A RTM usa o registro EAX para comunicar o estado de aborto ao software. Após um aborto de RTM, o registro EAX tem a seguinte definição.

[0045] O estado de aborto EAX para RTM fornece apenas as causas dos abortos. Ele não codifica em si se um aborto ou confirmação ocorreu para a região de RTM. O valor de EAX pode ser 0 após um aborto de RTM. Por exemplo, uma instrução CPUID, quando usada dentro de uma região de RTM, causa um aborto transacional e pode não satisfazer os requisitos para definir qualquer um dos bits de EAX. Isto pode resultar em um valor EAX de 0.

Ordenação de Memória RTM

[0046] Uma confirmação de RTM bem sucedida faz com que todas as operações de memória na região de RTM pareçam ser executadas de forma atômica. Uma região de RTM confirmada com sucesso consiste em uma XBEGIN seguido por uma XEND, mesmo sem operações de memória na região de RTM, tem a mesma semântica de ordenação que uma instrução de prefixo LOCK.

[0047] A instrução XBEGIN não tem semântica de limite. No entanto, se uma execução RTM é abortada, então, todas as atualizações de memória dentro da região de RTM são descartadas e não são tornadas visíveis a qualquer outro processador lógico.

Suporte ao Debugger Habilitado para RTM

[0048] Por padrão, qualquer exceção de debug dentro de uma região de RTM causará um aborto transacional e redirecionará o fluxo de controle para revogação do endereço de instrução com o estado arquitetônico recuperado e bit 4 no conjunto EAX. No entanto, para permitir que os debuggers de software interceptem a execução em exceções de debug, a arquitetura RTM fornece recursos adicionais.

[0049] Se o bit 11 de DR7 e o bit 15 de IA32 DEBUGCTL MSR são ambos 1, qualquer aborto de RTM em virtude de uma exceção de debug (#DB) ou exceção de ponto de ruptura (#BP) faz com que a execução seja retornada e reiniciada a partir da instrução XBEGIN, em vez de revogação de endereço. Neste cenário, o registro EAX também será restaurado ao ponto da instrução XBEGIN.

Considerações de Programação

[0050] Espera-se que regiões típicas identificadas por programador sejam executadas de forma transacional e confirmadas com êxito. No entanto, o Intel TSX não fornece nenhuma destas garantias. Uma execução transacional pode ser abortada, por muitas razões. Para aproveitar ao máximo as capacidades de transação, os programadores devem seguir determinadas diretrizes para aumentar a probabilidade de sua confirmação de execução transacional com êxito.

[0051] Esta seção discute vários eventos que podem causar um aborto transacional.

[0052] A arquitetura garante que as atualizações executadas dentro de uma transação que subsequentemente aborta a execução nunca se tornarão visíveis. Somente execuções transacionais confirmadas iniciam uma atualização para o estado arquitetônico. Abortos transacionais nunca causam falhas funcionais e só afetam o desempenho. Considerações Com Base na Instrução

[0053] Os programadores podem usar qualquer instrução com segurança dentro de uma transação (HLE ou RTM) e podem usar transações em qualquer nível de privilégio. No entanto, algumas instruções sempre abortam a execução e causam execução transacional para transição sem problemas e com segurança para um percurso não transacional.

[0054] O Intel TSX permite que as instruções mais comuns sejam usadas dentro de transações sem causar abortos. As operações a seguir dentro de uma transação não costumam causar um aborto: • operações no registro do apontador de instrução, registros de finalidade geral (GPRs) e sinalizadores de estado (CF, OF, SF, PF, AF e ZF); e • operações em registros XMM e YMM e no registro MXCSR.

[0055] No entanto, os programadores devem ter cuidado quando de mistura de operações SSE e AVX dentro de uma região transacional. A mistura de instruções SSE que acessam os registros XMM e instruções AVX que acessam os registros YMM pode fazer com que as operações sejam abortadas. Os programadores podem usar operações em cadeia de prefixo REP/REPNE dentro das transações.

[0056] No entanto, cadeias longas pode causar abortos. Além disso, o uso de instruções de CFD e DST podem causar abortos se elas alteram o valor do sinalizador DF. No entanto, se DF é 1, a instrução DST não causará um aborto. Da mesma forma, se DF é 0, então, a instrução CFD não causará um aborto.

[0057] As instruções não enumeradas aqui como causando abortos quando usadas dentro de uma operação normalmente não causarão o aborto de uma transação (exemplos incluem, porém sem limitações, MFENCE, FFENCE, SFENCE, RDTSC, RDTSCP, etc.).

[0058] As instruções a seguir abortarão a execução transacional em qualquer implementação: • XABORT • CPUID • PAUSE

[0059] Além disso, em algumas implementações, as instruções a seguir sempre podem causar um aborto transacional. Não se espera que estas instruções sejam usadas dentro de regiões transacionais típicas. No entanto, os programadores não deve contar com estas instruções para forçar um aborto transacional, uma vez que se elas causam abortos transacionais, depende da implementação. • Operações no estado de arquitetura X87 e MMX. Isto inclui todas as instruções MMX e x87, incluindo as instruções FXRSTOR e FXSAVE. • Atualizar para a porção sem estado de EFFAGS: CFI, STI, POPFD, POPFQ, CFTs. • Instruções que atualizam registros de segmento, registros de debug e/ou registros de controle: MOV para DS/ES/FS/GS/SS, POP DS/ES/FS/GS/SS, LDS, LES, LFS, LGS, LSS, SWAPGS, WRFSBASE , WRGSBASE, LGDT, SGDT, LIDT, SIDT, LLDT, SLDT, LTR, STR, Far CALL, Far JMP, Far RET, IRET, MOV para DRx, MOV para CR0/CR2/CR3/CR4/CR8 e FMSW. • Transições de anel: SYSENTER, SYSCAFF, SYSEXIT e SYSRET. • TFB e controle de capacidade em cache: CFFFUSH, INVD, WBINVD, INVFPG, INVPCID e instruções de memória com uma sugestão não temporal (MOVNTDQA, MOVNTDQ, MOVNTI, MOVNTPD, MOVNTPS e MOVNTQ). • Salvar estado do processador: XSAVE, XSAVEOPT e XRSTOR. • Interrupções: INTn, INTO. • IO: IN, INS, REP INS, para fora, saídas, saídas REP e suas variantes. • VMX: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXOFF, VMXON, INVEPT e INVVPID. • SMX: GETSEC. • UD2, RSM, RDMSR, WRMSR, HLT, MONITOR, MWAIT, XSETBV, VZEROUPPER, MASKMOVQ e V/MASKMOVDQU.

Considerações de Tempo de Execução

[0060] Além das considerações com base em instrução, eventos de tempo de execução pode fazer com que a execução de transações seja abortada. Estes podem ser em virtude de padrões de acesso a dados ou recursos de implementação de micro arquitetura. A lista a seguir não é uma discussão abrangente de todas as causas para um aborto.

[0061] Qualquer falha ou erro em uma transação que deve ser exposta ao software será suprimido. A execução transacional será abortada e a execução mudará para uma execução não transacional, como se a falha ou erro nunca tivesse ocorrido. Se uma exceção não é mascarada, então, esta exceção não mascarada resultará em um aborto transacional e o estado aparecerá como se a exceção nunca tivesse ocorrido.

[0062] Eventos de exceção síncronas (#DE, #OF, #NP, #SS, #GP, #BR, #UD, #AC, #XF, #PF, #NM, #TS, #MF, #DB, #BP/INT3) que ocorrem durante a execução transacional podem fazer com que uma execução não seja confirmada de forma transacional e requerer uma execução não transacional. Estes eventos são suprimidos como se nunca tivessem ocorrido. Com HFE, uma vez que o percurso de código não transacional é idêntico ao percurso de código transacional, estes eventos normalmente voltarão a aparecer quando a instrução que causou a exceção não transacional é executado novamente, fazendo com que os eventos síncronos associados sejam apropriadamente distribuídos na execução não transacional. Eventos assíncronos (NMI, SMI, INTR, IPI, PMI, etc.) que ocorrem durante a execução transacional podem fazer com que a execução transacional seja abortada e mude para uma execução não transacional. Os eventos assíncronos estarão pendentes e serão manipulados após o aborto transacional ser processado.

[0063] As transações dão suporte apenas a operações de tipo memória em cache de regravação. A transação sempre pode ser abortada se a transação inclui operações em qualquer outro tipo de memória. Isto inclui instruções obtidas do tipo de memória UC.

[0064] Acessos à memória dentro de uma região transacional podem requerer que o processador defina os sinalizadores Accessed and Dirty da entrada na tabela de página referenciada. O comportamento de como o processador lida com isto é específico para a implementação. Algumas implementações podem permitir que as atualizações para estes sinalizadores se tornem externamente visíveis mesmo se a região transacional é posteriormente abortada. Algumas implementações Intel TSX podem optar por abortar a execução transacional se estes sinalizadores precisam ser atualizados. Além disso, a página da tabela de um processador pode gerar acessos ao seu próprio estado gravado de forma transacional, mas não confirmado. Algumas implementações Intel TSX podem optar por abortar a execução de uma região transacional em tais situações. Independentemente disso, a arquitetura garante que, se a região transacional é abortada, então, o estado gravado de forma transacional não será se tornará arquitetonicamente visível através do comportamento de estruturas, tais como TLBs.

[0065] A execução do código de auto modificação de forma transacional também pode causar um aborto transacional. Os programadores devem continuar a seguir as diretrizes recomendadas pela Intel para gravação do código de auto modificação e do código de inter-modificação mesmo quando de emprego de HLE e RTM. Embora uma implementação de RTM e HLE normalmente forneça recursos suficientes para a execução de regiões transacionais em comum, restrições de implementação e tamanhos excessivos para regiões transacionais podem fazer com que uma execução transacional seja abortada e mude para uma execução não transacional. A arquitetura não fornece nenhuma garantia da quantidade de recursos disponíveis para fazer a execução transacional e não garante que uma execução transacional sempre seja bem sucedida.

[0066] Solicitações conflitantes a uma linha de cache acessada dentro de uma região transacional podem impedir que a transação seja executada com êxito. Por exemplo, se o processador lógico P0 lê a linha A em uma região transacional e outro processador lógico P1 grava a linha A (seja dentro ou fora de uma região transacional), então, o processador lógico P0 pode abortar se a gravação do processador lógico P1 interfere com a capacidade do processador P0 de executar a transação.

[0067] Similarmente, se P0 grava a linha A em uma região transacional e P1 lê ou grava a linha A (dentro ou fora de uma região transacional), então, P0 pode abortar se o acesso de P1 à linha A interfere com a capacidade de P0 de executar a transação. Além disso, outro tráfego de coerência pode, algumas vezes, aparecer como solicitações conflitantes e pode causar abortos. Embora estes falsos conflitos possam acontecer, espera-se que eles sejam incomuns. A política de resolução de conflitos para determinar se P0 ou P1 aborta nas situações acima é específica para a implementação. Concretizações Execução de Transação Genérica:

[0068] De acordo com "ARCHITECTURES FOR TRANSACTIONAL MEMORY", uma dissertação apresentada ao Department of Computer Science and the Committee on Graduate Studies of Stanford University em cumprimento parcial dos requisitos para obtenção do grau de Doutor em Filosofia, por Austen McDonald, Junho de 2009, incorporado por referência na íntegra, fundamentalmente, há três mecanismos necessários para implementar uma região transacional atômica e isolada: controle de versões, detecção de conflitos e gestão de contenção.

[0069] Para fazer uma região de código transacional parecer atômica, todas as modificações realizadas por esta região de código transacional devem ser armazenadas e mantidas isoladas das outras transações até o momento de confirmação. O sistema faz isto através da implementação de uma política de controle de versões. Há dois paradigmas de controle de versão: "eager" (ansioso) e "lazy" (preguiçoso). Um sistema de controle de versões "eager" armazena valores transacionais recém-gerados no local e armazena valores de memória anteriores ao lado, naquilo que é denominado um "desfazer log". Um sistema de controle de versões "lazy" armazena valores recém-gerados temporariamente naquilo que é denominado um buffer em branco, copiando-os para a memória apenas quando de confirmação. Em qualquer sistema, o cache é usado para otimizar o armazenamento de novas versões.

[0070] Para assegurar que as transações pareçam ser realizadas de forma atômica, conflitos devem ser detectados e resolvidos. Os dois sistemas, ou seja, os sistemas de controle de versões "eager" e "lazy", detectam conflitos através da implementação de uma política de detecção de conflitos, seja otimista ou pessimista. Um sistema otimista executa operações em paralelo, verificando conflitos apenas quando uma transação é confirmada. Um sistema pessimista verifica a existência de conflitos em cada carga e armazena. Similar ao controle de versões, a detecção de conflitos também usa o cache, marcando cada linha como parte do conjunto de leitura, parte do conjunto de gravação ou ambos. Os dois sistemas resolvem conflitos através da implementação de uma política de gestão de contenção. Há muitas políticas de gestão de contenção, algumas são mais apropriadas para a detecção de conflitos otimista e algumas são mais apropriadas para pessimista. São descritas abaixo algumas políticas exemplificativas.

[0071] Uma vez que cada memória transacional (TM) do sistema precisa tanto de detecção de controle de versões quanto detecção de conflitos, estas opções dão origem a quatro concepções de TM distintas: Eager-Pessimistic (EP), Eager-Optimistic (EO), Lazy-Pessimistic (LP) e Lazy- Optimistic (LO) . A Tabela 2 descreve brevemente as quatro concepções de TM distintas.

[0072] As Figuras 1 e 2 mostram um exemplo de um ambiente de TM com múltiplos núcleos. A Figura 1 mostra muitas CPUs com TM habilitada (CPU1 114a, CPU2 114b, etc.) sobre uma matriz 100, conectadas com uma interconexão 122, sob a gestão de um controle de interconexão 120a, 120b. Cada CPU 114a, 114b (também conhecida como um processador) pode ter um cache separado que consiste em um Cache de Instrução 116a, 166b para armazenamento em cache de instruções a partir de uma memória a ser executada e um Cache de Dados 118a, 118b, com suporte à TM para armazenamento em cache de dados (operandos) de locais de memória a serem operados pela CPU 114a, 114b (na Figura 1, cada CPU 114a, 114b e seus caches associados são citados como 112a, 112b). Em uma implementação, caches de múltiplas matrizes 100 são interconectados para dar suporte à coerência de cache entre os caches das múltiplas matrizes 100. Em uma implementação, um único cache, em vez dos cache separados, é empregado o qual contém tanto instruções quanto dados. Em implementações, as caches de CPU são um nível de armazenamento em cache em uma estrutura de cache hierárquico. Por exemplo, cada matriz 100 pode empregar um cache compartilhado 124 a ser compartilhado entre todas as CPUs na matriz 100. Em outra implementação, cada matriz pode ter acesso a um cache compartilhado 124, compartilhado entre todos os processadores de todas as matrizes 100.

[0073] A Figura 2 mostra os detalhes de uma CPU transacional 114 exemplificativa, incluindo adições ao suporte TM. A CPU transacional (processador) 114 pode incluir hardware para dar suporte a Pontos de Verificação de Registro 126 e Registros de TM 128 especiais. O cache da CPU transacional pode ter os bits MESI 130, Tags 140 e Dados 142 de um cache convencional, mas também, por exemplo, bits R 132 que mostram uma linha que foi lida pela CPU 114 durante a execução de uma transação e bits W 138 que mostram que uma linha foi gravada pela CPU 114 durante a execução de uma transação.

[0074] Um detalhe fundamental para programadores em qualquer sistema TM é como acessos não transacionais interagem com as transações. Por concepção, acessos transacionais são selecionados entre si usando os mecanismos acima. No entanto, a interação entre uma carga não transacional normal com uma transação que contém um novo valor para este endereço ainda deve ser considerada. Além disso, a interação entre um armazenamento não transacional com uma transação que tenha lido este endereço também deve ser explorada. Estas são questões de isolamento de conceito de banco de dados.

[0075] Um sistema TM é dito como implementando um forte isolamento, algumas vezes denominado atomicidade forte, quando cada carga e armazenamento não transacionais atua como uma transação atômica. Portanto, as cargas não transacionais não podem ver dados não confirmados e armazenamentos não transacionais causam violações na atomicidade em quaisquer transações que leram este endereço. Um sistema onde este não é o caso é dito como implementando um isolamento fraco, algumas vezes denominado de atomicidade fraca.

[0076] Um isolamento forte muitas vezes é mais desejável do que o isolamento fraco em virtude da relativa facilidade de conceitualização e implementação do isolamento forte. Além disso, se um programador esqueceu de limitar algumas referências de memória compartilhada com transações, causando erros, então, com o isolamento forte, o programador muitas vezes detectará este esquecimento usando uma interface de debug simples porque o programador verá uma região não transacional causando violações de atomicidade. Além disso, programas gravados em um modelo podem funcionar de forma diferente em outro modelo.

[0077] Além disso, muitas vezes é mais fácil obter suporte ao isolamento forte na TM em hardware do que um isolamento fraco. Com o isolamento forte, uma vez que o protocolo de coerência já gerencia a comunicação de carga e armazenamento entre os processadores, as transações podem detectar cargas e armazenamentos não transacionais e atuar de forma adequada. Para implementar o isolamento forte em Memória Transacional (TM) em software, o código não transacional deve ser modificado para incluir barreiras de leitura e gravação, incapacitando potencialmente o desempenho. Embora grande esforço tenha sido dispendido para remover muitas barreiras desnecessárias, tais técnicas frequentemente são complexas e o desempenho é, tipicamente, muito menor do que aquele de HTMs. Tabela 2 Espaço de Concepção de Memória Transacional CONTROLE DE VERSÕES

[0078] A Tabela 2 ilustra o espaço de concepção fundamental de memória transacional (controle de versões e detecção de conflitos).

Eager-Pessimistic (EP)

[0079] Esta primeira concepção de TM descrita a seguir é conhecida como Eager-Pessimistic. Um sistema EP armazena seu conjunto de gravação " no local " (daí o nome "eager" - impaciente) e, para dar suporte à reversão, armazena os valores antigos de linhas sobrescritas em um "undo log". Processadores usam os bits de cache W 138 e R 132 para rastrear os conjuntos de leitura e gravação e detectar conflitos quando de recebimento de solicitações de carga interceptadas. Talvez os exemplos mais notáveis de sistemas EP conhecidos na literatura sejam LogTM e UTM.

[0080] Começar uma operação em um sistema EP é muito parecido com começar uma transação em outros sistemas: tm_begin() toma um ponto de verificação de registro e inicializa quaisquer registros de estado. Um sistema EP também requer a inicialização de "undo log", cujos detalhes são dependentes do formato de registro porém, muitas vezes, envolve a inicialização de um ponteiro com base em log a uma região de memória de linha de instruções privada pré-alocada e limpeza de um log que limita o registro.

[0081] Controle de Versões: Em EP, em virtude da forma pela qual o controle de versões "eager" é concebido para funcionar, as transições de Estado MESI 130 (indicadores de linha de cache que correspondem aos Estados de código modificado, exclusivo, compartilhado e inválido) são deixadas praticamente inalteradas. Fora de uma transação, as transições de estado MESI 130 são deixadas completamente inalteradas. Quando de leitura de uma linha dentro de uma transação, as transições de coerência convencionais se aplicam (S (Compartilhado) ^ S, I (Inválido) ^ S ou I ^ E (Exclusivo)), emitindo uma falha de carga conforme necessário, mas o bit R 132 também é definido. Da mesma forma, a gravação de uma linha aplica as transições convencionais (S ^ M, E ^ 1,1 ^ M), emitindo uma falha quando necessário, mas também define o bit W 138 (gravação) . A primeira vez que uma linha é gravada, a versão antiga da linha inteira é carregada, então, gravada no registro de "undo log" para preservá-la no caso em que a transação atual é abortada. Os dados recém gravados são, então, armazenados "no local" sobre os dados antigos.

[0082] Detecção de Conflitos: A detecção de conflitos pessimista usa mensagens de coerência trocadas quando de falhas, ou upgrades, para procurar conflitos entre as transações. Quando uma falha de leitura ocorre dentro de uma transação, outros processadores recebem uma solicitação de carga; mas eles ignoram a solicitação se não têm a linha necessária. Se os outros processadores têm a linha necessária de forma não especulativa ou têm a linha R 132 (Leitura), eles rebaixam essa linha para S e, em determinados casos, emitem uma transferência de cache-para-cache se eles têm a linha no estado M ou E em MESEs 130. No entanto, se o cache tem a linha W 138, então, um conflito é detectado entre as duas transações e medida(s) adicional(is) deve(m) ser tomada(s).

[0083] Similarmente, quando uma transação busca atualizar uma linha de compartilhada para modificada (em uma primeira gravação), a transação emite uma solicitação de carga exclusiva, a qual também é usada para detectar conflitos. Se um cache de recepção tem a linha de forma não especulativa, então, a linha não é confirmada e, em determinados casos, uma transferência de cache-para-cache (estados M ou E) é emitida. Mas, se a linha é R 132 ou W 138, é detectado um conflito. Validação: Uma vez que a detecção de conflitos é realizada sobre cada carga, uma transação sempre tem acesso exclusivo ao seu próprio conjunto de gravação. Portanto, a validação não requer qualquer trabalho adicional. Confirmação: Uma vez que o controle de versões "eager" armazena a nova versão de itens de dados no local, o processo de confirmação simplesmente limpa os bits W 138 e R 132 e descarta o "undo log". Abortar: Quando uma transação é revertida, a versão original de cada linha de cache no "undo log" deve ser restaurada, um processo denominado de "unrolling" ou "aplicação" do log. Isto é feito durante tm_discart() e deve ser atômico em relação a outras transações. Especificamente, o conjunto de gravação ainda deve ser usado para detectar conflitos: esta transação tem a única versão correta de linhas em seu "undo log" e as transações solicitantes devem aguardar a versão correta ser restaurada a partir deste log. Tal log pode ser aplicado usando uma máquina de estado de hardware ou gerenciador de aborto em software.

[0084] Eager-Pessimistic tem as características de: a confirmação é simples e, uma vez que é no local, muito rápido. Da mesma forma, a confirmação é uma não-op. A detecção de conflitos pessimista detecta conflitos no início, deste modo, reduzindo o número de transações "condenadas". Por exemplo, se duas transações estão envolvidas em uma dependência de Gravação-Após-Leitura, então, esta dependência é detectada imediatamente em detecção de conflitos pessimista. No entanto, na detecção de conflitos otimista, tais conflitos não são detectados até que a confirmação da gravação.

[0085] Eager-Pessimistic também tem as características de: conforme descrito acima, a primeira vez que uma linha de cache é gravada, o valor antigo deve ser gravado no registro, incorrendo em acessos extra ao cache. Abortos são caros, uma vez que eles requerem desfazer o log. Para cada linha de cache no log, a carga deve ser emitida, talvez indo tão longe quanto a memória principal antes de continuar para a próxima linha. A detecção de conflitos pessimista também impede a existência de determinados esquemas passíveis de serialização.

[0086] Além disso, uma vez que os conflitos são gerenciados à medida que ocorrem, há um potencial para mecanismos de "livelock" e mecanismos de gestão de contenção cuidadosa devem ser empregados para garantir o progresso. Lazy-Optimistic (LO)

[0087] Uma outra concepção de TM popular é Lazy- Optimistic (LO), a qual armazena seu conjunto de gravação em um "buffer de gravação" ou "redo log" e detecta conflitos no momento de confirmação (ainda usando os bits R 132 e W 138) .

[0088] Controle de Versões: Assim como no sistema EP, o protocolo MESI da concepção LO é aplicado fora das transações. Uma vez dentro de uma transação, a leitura de uma linha incorre nas transições MESI convencionais, mas também define o bit R 132. Similarmente, a gravação de uma linha define o bit W 138 da linha, mas a manipulação das transições MESI da concepção LO é diferente daquela da concepção EP. Primeiro, com a versão "lazy", as novas versões dos dados gravados são armazenadas na hierarquia de cache até confirmação, enquanto que outras transações têm acesso a versões antigas disponíveis na memória ou outros caches. Para disponibilizar as versões antigas, linhas "dirty" (linhas M) devem ser expulsas quando gravadas pela primeira vez por uma transação. Em segundo, nenhuma atualização de falhas é necessária em virtude do recurso de detecção de conflitos otimista: se uma transação tem uma linha no estado S, ela pode simplesmente gravá-la e atualizar essa linha para um estado M sem comunicar as alterações com outras transações, pois a detecção de conflitos é feita no momento da confirmação.

[0089] Detecção de Conflitos e Validação: Para validar uma transação e detectar conflitos, LO comunica os endereços de linhas especulativamente modificadas para outras transações somente quando está se preparando para confirmar. Na validação, o processador envia um pacote de rede potencialmente grande que contém todos os endereços no conjunto de gravação. Os dados não são enviados, mas deixados no cache do "committer" e marcados "dirty" (M). Para construir este pacote sem pesquisar o cache por linhas marcadas W, um vetor de bits simples é usado, denominado "buffer de armazenamento", com um bit por linha de cache para rastrear estas linhas especulativamente modificadas. Outras transações usar este pacote de endereços para detectar conflitos: se um endereço é encontrado no cache e o bit R 132 e/ou W 138 são definidos, então, um conflito se inicia. Se a linha é encontrada, mas nem R 132 nem W 138 é definido, então, a linha é simplesmente invalidada, o qual é similar ao processamento de uma carga exclusiva.

[0090] Para dar suporte à atomicidade da transação, estes pacotes de endereço devem ser tratados atomicamente, ou seja, pode não existem dois pacotes de endereços de uma vez com os mesmos endereços. Em um sistema LO, isto pode ser conseguido simplesmente ao adquirir um "token" de confirmação global antes de enviar o pacote de endereços. No entanto, um esquema de confirmação em duas fases poderia ser empregado primeiro ao enviar o pacote de endereços, coletar respostas, impor um protocolo de ordenação (talvez transação mais antiga primeiro) e confirmar uma vez que todas as respostas sejam satisfatórias.

[0091] Confirmação: Uma vez que a validação ocorreu, a confirmação não requer tratamento especial: simplesmente limpar os bits W 138 e R 132 e o buffer de armazenamento. As gravações da transação já estão marcadas "dirty" no cache e outras cópias em caches destas linhas foram invalidadas através do pacote de endereços. Outros processadores podem, então, acessar os dados confirmados através do protocolo de coerência regular.

[0092] Abortar: Reversão é igualmente fácil: uma vez que o conjunto de gravação está contido dentro dos caches locais, estas linhas podem ser invalidadas, então, limpar os bits W 138 e R 132 e o buffer de armazenamento. O buffer de armazenamento permite que linhas W sejam encontradas para invalidar sem a necessidade de buscar no cache.

[0093] Lazy-Optimistic tem as características de: Abortos são muito rápidos, sem a necessidade de cargas ou armazenamentos adicionais e faz apenas alterações locais. Podem existir esquemas mais serializáveis do que aquele encontrado em EP, permitindo que um sistema LO especule de forma mais agressiva quais transações são independentes, o que pode gerar um maior desempenho. Finalmente, a detecção final de conflitos pode aumentar a probabilidade de progresso.

[0094] Lazy-Optimistic também tem as características de: A validação leva um tempo para comunicação global proporcional ao tamanho do conjunto de gravação. Transações condenadas podem desperdiçar trabalho, uma vez que os conflitos são detectados apenas no momento da confirmação. Lazy-Pessimistic (LP)

[0095] Lazy-Pessimistic (LP) representa uma terceira opção de concepção TM, localizada em algum lugar entre PE e LO: armazena linhas recém gravadas em um buffer de gravação, mas detecta conflitos em uma base por acesso .

[0096] Controle de Versões: O controle de versões é similar, mas não idêntico àquele do LO: a leitura de uma linha define seu bit R 132, a gravação de uma linha define seu bit W 138 e um buffer de armazenamento é usado para rastrear as linhas W no cache. Além disso, linhas "dirty" (M) devem ser eliminadas quando se grava pela primeira vez uma transação, assim como em LO. No entanto, uma vez que a detecção de conflitos é pessimista, exclusões de carga devem ser realizadas quando de atualização de uma linha transacional de I, S ^ M, o que é diferente de LO.

[0097] Detecção de Conflitos: A detecção de conflitos em LP funciona da mesma forma que em EP: usando mensagens de coerência para procurar conflitos entre transações.

[0098] Validação: Conforme em EP, a detecção de conflitos pessimista garante que, em qualquer ponto, uma transação em execução não tenha conflitos com qualquer outra transação em execução, de modo que a validação é ano-op.

[0099] Confirmação: A confirmação não requer tratamento especial: simplesmente limpar os bits W 138 e R 132 e o buffer de armazenamento, conforme em LO.

[0100] Abortar: Reversão também é conforme em LO: simplesmente invalidar o conjunto de gravação usando o buffer de armazenamento e limpar os bits W e R e o buffer de armazenamento.

Eager-Optimistic (EO)

[0101] O EO tem as características de: Assim como LO, abortos são muito rápidos. Como o EP, o uso de detecção de conflitos pessimista reduz o número de transações "condenadas". Como o EP, alguns esquemas serializáveis não são permitidos e a detecção de conflitos deve ser executada em cada cache.

[0102] A combinação final de controle de versões e detecção de conflitos é Eager-Optimistic (EO). EO pode ser uma escolha menos do que ideal para sistemas HTM: uma vez que novas versões transacionais são gravadas no local, outras transações não têm escolha senão anotar conflitos à medida que eles ocorrem (ou seja, à medida que ocorrerem erros de cache). Mas, uma vez que EO espera até o momento de confirmar para detectar conflitos, as transações se tornam "zumbis", continuam a ser executadas, desperdiçando recursos, ainda que estejam "condenadas" a abortar.

[0103] EO provou ser útil em STMs e é implementada pelo Bartok-STM e MCRT. A versão STM "lazy" precisa verificar seu buffer de gravação em cada leitura para garantir que ele está lendo o valor mais recente. Uma vez que a memória de gravação intermediária não é uma estrutura de hardware, isto é caro, daí a preferência pela versão "eager" de gravação no local. Além disso, uma vez que a verificação de conflitos também é cara em um STM, a detecção de conflitos otimista oferece a vantagem de executar esta operação em massa.

Gestão de Contenção

[0104] Como uma transação reverte uma vez que o sistema decidiu abortar esta operação foi descrito acima mas, uma vez que um conflito envolve duas transações, os tópicos de qual transação deve abortar, como este aborto deve ser iniciado e quando uma transação abortada deve ser repetida precisa ser explorado. Estes são tópicos que são abordados pela Gestão de Contenção (CM), um componente chave da memória transacional. São descritas abaixo políticas a respeito de como os sistemas iniciam abortos e os vários métodos estabelecidos para gerir quais transações devem ser abortadas em um conflito.

Políticas de Gestão de Contenção

[0105] A Política de Gestão de Contenção (CM) é um mecanismo que determina qual transação envolvida em um conflito deve ser abortada e quando a transação abortada deve ser repetida. Por exemplo, é frequente o caso que a repetição de uma transação abortada imediatamente não leva a um melhor desempenho. Por outro lado, o emprego de um mecanismo de recuo, o qual atrasa a repetição de uma transação abortada, pode render um melhor desempenho. STM foi a primeira a lutar para encontrar as melhores políticas de gestão de contenção e muitas das políticas descritas abaixo foram originalmente desenvolvidas para STM.

[0106] As políticas CM recorrem a uma série de medidas para tomar decisões, incluindo as idades das transações, tamanho dos conjuntos de leitura e gravação, o número de abortos anteriores, etc. As combinações de medidas para tomar tais decisões são infinitas, mas determinadas combinações são descritas abaixo, aproximadamente na ordem crescente de complexidade.

[0107] Para estabelecer alguma nomenclatura, primeiro observe que, em um conflito, há dois lados: o atacante e o defensor. O atacante é a transação que solicita acesso a um local de memória compartilhada. Na detecção de conflitos pessimista, o atacante é a transação que emite carga ou carga exclusiva. Em otimista, o atacante é a transação que tenta validar. A defesa em ambos os casos é a transação que recebe a solicitação do atacante.

[0108] Uma política CM agressiva repete imediatamente e sempre tanto o atacante quanto o defensor. Em LO, agressiva significa que o atacante sempre vence e, assim, agressiva algumas vezes é denominado "committer" vence. Tal política foi usada para os primeiros sistemas LO. No caso de EP, agressiva pode ser defensor vence ou atacante vence.

[0109] A reinicialização de uma transação conflitante em que experimentará imediatamente outro conflito está relacionada a desperdício de trabalho - ou seja, falhas de cache com recarga de largura de banda de interconexão. A Política CM emprega recuo exponencial (mas linear também pode ser usado) antes de reiniciar os conflitos. Para evitar privação, uma situação onde um processo não tem recursos alocados ao mesmo pelo programador, o recuo exponencial aumenta muito as chances de sucesso da transação após algumas n repetições.

[0110] Outra abordagem para a resolução de conflitos é abortar aleatoriamente o atacante ou defensor (a política denominada Randomizada). Tal política pode ser combinada com um esquema de recuo aleatório para evitar contenção desnecessária.

[0111] No entanto, fazer escolhas aleatórias, quando de escolha de uma transação para abortar, pode resultar em abortar transações que tenham sido concluídas com "muito trabalho" , o que pode desperdiçar recursos. Para evitar desperdício, a quantidade de trabalho realizado sobre a transação pode ser levada em consideração para determinar quais transações abortar. Uma medida de trabalho poderia ser a idade de uma transação. Outros métodos incluem Oldest, Bulk TM, Size Matters, Karma, and Polka. Oldest é um método de data e hora simples que anula a transação mais jovem em um conflito. Bulk TM usa este esquema. Size Matters é como o Oldest mas, em vez da idade da transação, o número de palavras na leitura/gravação é usado como a prioridade, revertendo para a mais antiga após um número fixo de abortos. Karma é similar, usando o tamanho do conjunto de gravação como prioridade. Reversão, então, prossegue após recuar uma quantidade fixa de tempo. Transações abortadas mantêm sua prioridade após serem abortadas (daí o nome Karma) . Polka funciona como o Karma mas, em vez de recuar uma quantidade predefinida de tempo, recua exponencialmente cada vez mais.

[0112] Uma vez que abortar desperdiça trabalho, é lógico argumentar que protelar um atacante até que o defensor termine sua operação levaria a um melhor desempenho. Infelizmente, um esquema tão simples leva facilmente a um impasse.

[0113] Técnicas de evasão impasse podem ser usadas para resolver este problema. Greedy usa duas regras para evitar impasse. A primeira regra é, se uma primeira operação, T1, tem prioridade mais baixa do que a segunda operação, T0, ou se T1 está esperando por outra transação, então, T1 é abortada quando em conflito com T0. A segunda regra é, se T1 tem maior prioridade do que T0 e não está esperando, então, T0 espera até que T1 seja confirmada, abortada ou inicie em espera (caso no qual a primeira regra é aplicada). Greedy fornece algumas garantias sobre limites de tempo para execução de um conjunto de transações. Uma concepção EP (LogTM) usa uma política CM similar a Greedy para alcançar estagnação com evasão de impasse conservadora.

[0114] As regras de coerência MESI exemplificativas preveem quatro estados possíveis nos quais uma linha de cache de um sistema de cache multiprocessador podem residir, M, E, S e I, definidos da seguinte forma: Modificado (M) : A linha de cache está presente apenas no cache atual e é "dirty"; ela foi modificada a partir do valor na memória principal. É necessário que o cache grave os dados novamente na memória principal em algum momento no futuro, antes de permitir qualquer outra leitura do estado da memória principal (não válido). A regravação muda a linha para o estado Exclusivo. Exclusivo (E): A linha de cache está presente apenas no cache atual, mas está limpa; ela corresponde à memória principal. Ela pode ser alterada para o estado compartilhado, a qualquer momento, em resposta a uma solicitação de leitura. Alternativamente, ela pode ser alterada para o estado modificado quando de gravação na mesma. Compartilhado (S): Indica que esta linha de cache pode ser armazenada em outros caches da máquina e é "limpa"; ele corresponde à memória principal. A linha pode ser descartada (alterada para o estado inválido) a qualquer momento. Inválido (I): Indica que esta linha de cache é inválida (não usada).

[0115] Indicadores de estado de coerência em TM (R 132, W 138) podem ser fornecidos para cada linha de cache, além de, ou codificados, nos bits de coerência MESI. Um indicador R 132 indica que a transação atual foi lida a partir dos dados da linha de cache e um indicador W 138 indica que a transação atual foi gravada nos dados da linha de cache.

[0116] Em outro aspecto da concepção TM, um sistema foi concebido usando buffers de armazenamento transacionais. A Patente dos Estados Unidos N° 6.349.361 intitulada "Methods and Apparatus for Reordering and Renaming Memory References in a Multiprocessor Computer System", depositada em 31 de março de 2000 e incorporada por referência na íntegra, ensina um método para reordenar e renomear referências à memória em uma sistema de computador multiprocessador que tem pelo menos um primeiro e um segundo processadores. O primeiro processador tem um primeiro cache privado e um primeiro buffer e o segundo processador tem um segundo cache privado e um segundo buffer. O método inclui as operações de, para cada uma de uma pluralidade de solicitações de armazenamento ativadas recebidas pelo primeiro processador para armazenar um dado, exclusivamente a aquisição de uma linha de cache que contém o dado pelo primeiro cache de privado e armazenamento do dado no primeiro buffer. Quando o primeiro buffer recebe a solicitação de carregamento a partir do primeiro processador para carregar um dado específico, o dado em particular é fornecido ao primeiro processador dentre os dados armazenados no primeiro buffer com base em uma sequência em ordem das operações de carregamento e armazenamento. Quando o primeiro cache recebe uma solicitação de carregamento a partir do segundo cache para um determinado dado, uma condição de erro é indicada e um estado atual de pelo menos um dos processadores é redefinido para um estado anterior quando a solicitação de carregamento para o determinado dado corresponde aos dados armazenados no primeiro buffer.

[0117] Os principais componentes de implementação de tal unidade de memória transacional são um arquivo de registro de backup de transação para a conter o conteúdo GR (registro geral) pré-transação, um diretório de cache para rastrear as linhas de cache acessadas durante a transação, um cache de armazenamento para armazenamentos em buffer até que a transação termine e rotinas de firmware para executar várias funções complexas. Nesta seção a implementação detalhada é descrita.

Concretização de Servidor Corporativo IBM zEnterprise EC12

[0118] O servidor corporativo IBM zEnterprise EC12 introduz execução transacional (TX) na memória transacional e é parcialmente descrito em um artigo, "Transactional Memory Architecture and Implementation for IBM System z" de Proceedings, Páginas 25-36, apresentado em MICRO-45, 01-05 dezembro de 2012, Vancouver, Columbia Britânica, Canadá, disponível a partir do IEEE Computer Society Conference Publishing Services (CPS), o qual é aqui incorporado por referência na íntegra.

[0119] A Tabela 3 mostra uma transação exemplificativa. As transações iniciadas com TBEGIN não têm a certeza de sempre serem concluídas com sucesso com TEND, uma vez que elas podem experimentar uma condição de abortar a cada tentativa de execução, por exemplo, em virtude de repetição de conflitos com outras CPUs. Isto requer que o programa dê suporte a um percurso de retorno para realizar a mesma operação de forma não transacional, por exemplo, usando esquemas de bloqueio tradicionais. Isto impõe uma carga significativa sobre as equipes de programação e verificação de software, especialmente onde o percurso de retorno não é gerado automaticamente por um compilador confiável. TABELA 3 Código de Transação Exemplificativo

[0120] A exigência de fornecer um percurso de retorno para execução da transação abortada (TX) pode ser onerosa. Espera-se que muitas transações que operam em estruturas de dados compartilhadas sejam curtas, toque apenas em alguns locais de memória distintos e usem apenas instruções simples. Para estas transações, o IBM zEnterprise EC12 introduz o conceito de transações restritas; sob condições normais, a CPU 114 assegura que as operações restritas eventualmente sejam concluídas com sucesso, embora sem fornecer um limite rigoroso sobre o número de repetições necessárias. Uma transação começa com uma instrução restrita TBEGINC e termina com um TEND normal. A implementação de uma tarefa como uma transação restrita ou não limitada normalmente resulta em um desempenho muito similar, mas as transações restritas simplificam o desenvolvimento de software ao eliminar a necessidade de um percurso de retorno. A arquitetura de Execução Transacional da IBM é ainda descrita em z/Architecture, Principies of Operation, décima edição, SA22-7832-09, publicada em setembro de 2012 pela IBM, incorporada por referência na íntegra.

[0121] Uma transação restrita começa com a instrução TBEGINC. Uma transação iniciada com TBEGINC deve seguir uma lista de restrições de programação; caso contrário, o programa faz uma interrupção por violação de restrição não filtrável. Restrições exemplificativas podem incluir, porém sem limitações: a transação pode executar um máximo de 32 instruções, todo o texto de instruções deve estar dentro de 256 bytes consecutivos de memória; a transação contém somente ramificações relativas apontando para a frente (isto é, sem loops ou chamadas de sub-rotinas); a transação pode acessar um máximo de 4 octowords alinhadas (uma octoword tem 32 bytes) de memória; e a restrição do conjunto de instruções exclui instruções complexas, tais como operações decimais ou de ponto flutuante. As restrições são escolhidas de tal forma que muitas operações comuns, tais como operações de eliminar/inserir lista duplamente relacionada, possam ser executadas, incluindo o muito poderoso conceito de objetivar comparação-e-troca atômicas de até 4 octowords alinhados. Ao mesmo tempo, as restrições foram escolhidas conservadoramente de tal forma que futuras implementações em CPU possam assegurar o sucesso da transação sem a necessidade de ajustar as restrições uma vez que, de outra forma, isto levaria à incompatibilidade de software.

[0122] TBEGINC se comporta principalmente como XBEGIN em TSX ou TBEGIN em servidores zEC12 da IBM, exceto que os campos controle de registro de ponto flutuante (FPR) e filtragem de interrupção de programa não existem e os controles são considerados nulos. Quando de aborto de uma transação, o endereço de instrução é redefinido diretamente para TBEGINC, em vez de para a instrução depois, refletindo a imediata repetição e ausência de um percurso de abortar para transações restritas.

[0123] Transações agrupadas não são permitidas dentro de transações restritas, mas se um TBEGINC ocorre dentro de uma transação não restrita, ela é tratada como a abertura de um novo nível de agrupamento não restrito apenas como TBEGIN faria. Isto pode ocorrer, por exemplo, se uma transação não restrita chama uma sub-rotina que usa uma transação restrita internamente.

[0124] Uma vez que a filtragem de interrupção está implicitamente inativa, todas as exceções durante uma transação restrita levam a uma interrupção no sistema operacional (OS). Eventual finalização com sucesso da transação depende da capacidade do OS de paginar no máximo 4 páginas tocadas por qualquer transação restrita. O OS também deve garantir trechos de tempo longos o suficiente para permitir que a transação seja concluída.

[0125] A Tabela 4 mostra a implementação de transação restrita do código na Tabela 3, partindo do princípio de que as transações restritas não interagem com outros códigos com base em bloqueio. Nenhum teste de bloqueio é mostrado, portanto, mas pode ser adicionado, se as transações restritas e código com base em bloqueio foram misturados.

[0126] Quando uma falha ocorre repetidamente, emulação de software é realizada usando milicódigo como parte do firmware de sistema. Vantajosamente, as operações restritas têm propriedades desejáveis em virtude da carga removida dos programadores.

[0127] Com referência à Figura 3, o processador zEnterprise EC12 da IBM introduziu a unidade de execução transacional . O processador pode decodificar 3 instruções por ciclo de "clock"; instruções simples são despachadas como micro-ops individuais e instruções mais complexas são divididas em vários micro-ops. Os micro-ops (Uops 232B) são gravados em uma fila de emissões unificada 216, a partir de onde eles podem ser emitidos fora de ordem. Até duas instruções de ponto fixo, uma de ponto flutuante, duas de carregamento/armazenamento e duas de ramificação podem ser executadas a cada ciclo. Uma Tabela de Conclusão Global (Global Conclusion Table - GCT) 232 mantém todos os microop e uma profundidade de agrupamento de transação (TND) 232a. A GCT 232 é gravada na ordem no momento de decodificação, rastreia o estado de execução de cada micro-op 232b e completa as instruções quando todos os micro-ops 232b do grupo de instruções mais antigo tenham sido executados com sucesso.

[0128] O cache de dados de nível 1 (L1) 240 é um cache associativo de 96KB (quilo bytes) de 6 vias com linhas de cache de 256 bytes e latência de uso de 4 ciclos, acoplado a um cache de dados de 2° nível (L2) associativo de 8 vias de 1MB (megabyte) privado 268 com penalidade por latência de uso de 7 ciclos para 240 falhas em L1. O cache L1 240 é o cache mais próximo de um processador e o cache Ln é um cache ao enésimo nível de armazenamento em cache. Ambos os caches L1 240 e L2 268 são de armazenamento em cache e em memória principal ("store-through") . Seis núcleos em cada chip de processador central (CP) compartilham um cache de armazenamento embutido de 3° nível de 48MB e seis chips de CP são conectados a um cache de 4° nível fora do chip de 384MB, acondicionados juntos em um módulo com múltiplos chips de vidro cerâmico (MCM). Até 4 módulos com múltiplos chips (MCM) podem ser conectados a um sistema multiprocessador (SMP) coerente simétrico com até 144 núcleos (nem todos os núcleos estão disponíveis para executar a carga de trabalho do cliente).

[0129] A coerência é gerida por uma variante do protocolo MESI. As linhas de cache podem ser de propriedade de leitura apenas (compartilhadas) ou exclusivas; L1 240 e L2 268 são de armazenamento em cache e em memória principal ("store-through") e, portanto, não contêm linhas "dirty". Os caches L3 e L4 272 (não mostrados) são de armazenamento embutido e rastreiam estados "dirty". Cada cache é inclusivo de todos os seus caches de nível mais baixo conectados.

[0130] Solicitações de coerência são denominadas "interrogação cruzada" (XI) e são enviadas hierarquicamente de caches de maior nível para caches de nível mais baixo e entre os L4s. Quando um núcleo falha em L1 240 e L2 268 e solicita a linha de cache a partir de seu local L3 272, o L3 272 verifica se ele possui a linha e, se necessário, envia uma XI para o L2 268/L1 240 concorrentemente sob este L3 272 para assegurar a coerência, antes de retornar a linha de cache para o solicitante. Se a solicitação também falha em L3 272, o L3 272 envia uma solicitação para L4 (não mostrado), o qual reforça a coerência ao enviar XIs para todos os L3s necessários sob este L4 e aos L4s vizinhos. Então, L4 responde ao L3 solicitante que envia a resposta para L2 268/L1 240.

[0131] Observe que, em virtude da regra de inclusão da hierarquia de cache, algumas vezes, as linhas de cache são interrogadas a partir dos caches de nível mais baixo devido a despejos em caches de nível mais alto causados por excessos de associatividade a partir de solicitações às outras linhas de cache. Estas interrogações podem ser denominadas "LRU XIs" , onde LRU significa menos usado recentemente.

[0132] Fazendo referência a um outro tipo de solicitações XI, Rebaixar-XIs muda a propriedade de cache de exclusivo para o estado de leitura apenas e Exclusivo-XIs muda para a propriedade de cache de exclusivo para inválido. Rebaixar-XIs e Exclusivo-XIs precisam de uma resposta de volta ao solicitante de XI. O cache alvo pode "aceitar" a XI ou enviar uma resposta de "rejeitar" se ele primeiro precisa despejar dados "dirty" antes de aceitar a XI. Os caches L1 240/L2 268 são de armazenamento em cache e em memória principal ("store-through"), mas podem rejeitar Rebaixar-XIs e Exclusivo-XIs se eles têm armazenamentos em suas filas de armazenamento que precisam ser enviados para L3 antes de rebaixar o estado para exclusivo. A XI rejeitada será repetida pelo solicitante. Leitura-apenas-XIs são enviados para caches que possuem a linha de leitura apenas; nenhuma resposta é necessária para tais XIs, uma vez que elas não podem ser rejeitadas. Os detalhes do protocolo SMP são similares àqueles descritos para o IBM Z10 por P. Mak, C. Walters e G. Strait em "IBM System z10 processor cache subsystem microarchitecture", IBM Journal of Research and Development, Vol. 53: 1, de 2009, o qual é aqui incorporado por referência na íntegra.

Execução de Instrução Transacional

[0133] A Figura 3 ilustra componentes exemplificativos de um ambiente de CPU 112 exemplificativo, incluindo uma CPU 114 e caches/componentes com os quais ela interage (tais como aqueles representados nas Figuras 1 e 2) . A unidade de decodificação de instruções (Instruction Decode Unit - IDU) 208 mantém o controle da profundidade de agrupamento da transação atual 212 (TND). Quando a IDU 208 recebe uma instrução TBEGIN, a profundidade de agrupamento 212 é incrementada e, inversamente diminuída em instruções TEND. A profundidade de agrupamento 212 é gravada na GCT 232 para todas as instruções despachadas. Quando um TBEGIN ou TEND é decodificado em um percurso especulativo que depois é liberado, a profundidade de agrupamento 212 da UDI 208 é atualizada a partir da entrada em GCT mais recente 232 que não está liberada. O estado transacional também é gravado na fila de emissões 216 para consumo pelas unidades de execução, principalmente pela Unidade de carregamento/armazenamento (Load/Store Unit - LSU) 280, a qual também tem uma calculadora de endereços 236 eficaz incluída na LSU 280. A instrução TBEGIN pode especificar um bloco de diagnóstico transação (Transaction Diagnostic Block - TDB) para gravar as informações de estado, se a transação é abortada antes de atingir uma instrução TEND.

[0134] Similar à profundidade de agrupamento, a IDU 208/GCT 232 rastreiam de forma colaborativa máscaras de modificação de registro de acesso/registro de ponto flutuante (AR/FPR) através do grupo de transações; a IDU 208 pode colocar uma solicitação de aborto na GCT 232 quando uma instrução de modificação de AR/FPR é decodificada e a máscara de modificação a bloqueia. Quando a instrução se torna quase completa, a conclusão é bloqueada e a transação é abortada. Outras instruções restritas são tratadas da mesma forma, incluindo TBEGIN, se descodificada enquanto em uma transação restrita ou quando excede a profundidade máxima de agrupamento.

[0135] Um TBEGIN mais externo é dividido em vários micro-ops, dependendo do GR-Salve-Mask; cada micro-op 232b (incluindo, por exemplo, uop 0, uop 1 e uop2) será executado por uma das duas unidades de ponto fixo (Fixed Point Units - FXUs) 220 para salvar um par de GRs 228 em um arquivo de registro de backup de transações 224 especial, o qual é usado para restabelecer posteriormente o conteúdo do GR 228 no caso de aborto de uma transação. Também, o TBEGIN cria microops 232b para executar um teste de acessibilidade para o TDB se um é especificado; o endereço é salvo em um registro de finalidade específica para uso posterior no caso de aborto. Na decodificação de um TBEGIN mais externo, o endereço de instrução e o texto de instrução do TBEGIN também são salvos em registros de finalidade específico para um potencial processamento de aborto posteriormente.

[0136] TEND e NTSTG são instruções em micro-op 232b individuais; NTSTG (armazenamento não transacional) é tratado como um armazenamento normal, exceto que ele é marcado como não transacional na fila de emissões 216, de modo que a LSU 280 possa tratá-lo apropriadamente. TEND é um não-op no momento de execução, o final da transação é realizado quando TEND é concluído.

[0137] Conforme mencionado, as instruções que estão dentro de uma transação são marcadas como tal na fila de emissão 216 mas, caso contrário, são executadas praticamente inalteradas; a LSU 280 realiza rastreio de isolamento conforme descrito na próxima seção.

[0138] Uma vez que a decodificação está em ordem e uma vez que a IDU 208 mantém o rastreio do estado transacional atual e grava o mesmo na fila de emissões 216, juntamente com todas as instruções da transação, a execução de TBEGIN, TEND e instruções antes, dentro e após a transação podem ser executadas fora de ordem. É mesmo possível (embora improvável) que TEND seja executado primeiro, então, toda a transação e, por último, TBEGIN é executado. A ordem do programa é restaurada através da GCT 232 no momento de conclusão. O comprimento das transações não é limitado pelo tamanho da GCT 232, uma vez que registros de finalidade geral (GRs) 228 podem ser restaurados a partir do arquivo de registro de backup 224.

[0139] Durante a execução, os eventos de registro de evento de programa (Program Event Recording - PER) são filtrados com base no Controle de Supressão de Eventos e um evento PER TEND é detectado se habilitado. Da mesma forma, enquanto no modo transacional, um gerador pseudoaleatório pode estar causando abortos aleatórios como ativado pelo Controle de Diagnóstico de Transação.

Rastreio para Isolamento Transacional

[0140] A Unidade de Carregamento/Armazenamento rastreia linhas de cache 280 que foram acessadas durante a execução transacional e desencadeia um aborto se uma XI de outra CPU (ou uma LRU-XI) entra em conflito com o perfil ("footprint"). Se a XI conflitante é uma XI exclusiva ou de rebaixar, a LSU 280 rejeita a XI de volta para o L3 272 na esperança de terminar a transação antes que o L3 272 repita a XI. Este "braço rígido" é muito eficiente em transações altamente competitivas. De modo a evitar travamentos quando duas CPUs entram em braço rígido uma com a outra, um contador de rejeição de XI é implementado, o qual desencadeia um aborto de transação quando um limite é atingido.

[0141] O diretório de cache L1 240 é, tradicionalmente, implementado com memórias de acesso aleatório estáticas (Static Random Access Memories - SRAMs). Para a implementação de memória transacional, os 244 bits válidos (64 linhas x 6 maneiras) do diretório foram movidos para "latches" de lógica normal e são complementados com mais dois bits por linha de cache: o bit 248 de TX-read e o bit 252 de TX-dirty.

[0142] O bit 248 de TX-read é reiniciado quando um novo TBEGIN mais externo é decodificado (o qual é interligado contra uma transação anterior ainda pendente) . O bit 248 de TX-read é definido no momento da execução de cada instrução de carregamento que está marcada "transacional" na fila de emissão. Observe que isto pode levar à sobre-marcação se carregamentos especulativos são executados, por exemplo, sobre um percurso de ramificação imprevisto. A alternativo de definir o bit 248 de TX-read no momento de conclusão de carregamento era muito caro para a área do Silício, uma vez que vários carregamentos podem ser concluídos ao mesmo tempo, requerendo muitas portas de leitura na fila de emissões.

[0143] Armazenamentos são executados da mesma maneira conforme no modo não transacional, mas uma marca de transação é colocada na entrada da fila de armazenamento (STQ) 260 da instrução de armazenamento. No momento de regravação, quando os dados provenientes da STQ 260 são gravados no L1 240, o bit 252 de TX-dirty no diretório L1 256 é definido para a linha de cache gravada. A regravação de armazenamento em L1 240 ocorre apenas após a instrução de armazenamento ser concluída e, no máximo, um armazenamento é revertido por ciclo. Antes da conclusão e regravação, os carregamentos podem acessar os dados da STQ 260 por meio de encaminhamento de armazenamento; após regravação, a CPU 114 (Figura 2) pode acessar os dados especulativamente atualizados em L1 240. Se a transação termina com sucesso, o bit 253 de TX-dirty de todas as linhas de cache é limpo e também as TX-marcas de armazenamentos ainda não gravados são apagadas na STQ 260, transformando eficazmente os armazenamentos pendentes em armazenamentos normais.

[0144] Em um aborto de transação, todos os armazenamentos transacionais pendentes são invalidados da STQ 260, mesmo aqueles já concluídos. Todas as linhas de cache que foram modificadas pela transação em L1 240, isto é, têm o bit 252 de TX-dirty em diante, têm seus bits válidos desativados, removendo-os efetivamente do cache L1 240 instantaneamente.

[0145] A arquitetura requer que, antes de completar uma nova instrução, o isolamento do conjunto de leitura e gravação da transação seja mantido. Este isolamento é assegurado ao protelar a conclusão de instruções em momentos adequados quando XIs estão pendentes; execução especulativa fora de ordem é permitida assumindo, de forma otimista, que as XIs pendentes são para endereços diferentes e realmente não causam um conflito de transação. Esta concepção se adapta muito naturalmente aos bloqueios de XI-vs-conclusão que são implementados em sistemas do estado da técnica para garantir a forte ordenação de memória que a arquitetura requer.

[0146] Quando o L1 240 recebe uma XI, o L1 240 acessa o diretório para verificar a validade do endereço da XI no L1 240 e, se o bit 248 de TX-read está ativo na linha XLed e a XI não é rejeitada, a LSU 280 desencadeia um aborto. Quando uma linha de cache com o o bit 248 de TX-read ativo é enviada para a LRU a partir do L1 240, um vetor de LRU- extensão especial se recorda de cada uma das 64 linhas do L1 240 onde uma linha de TX-read existia nesta linha. Uma vez que não há rastreio de endereço exato para as extensões de LRU, qualquer XI não rejeitada que atinge uma linha de extensão válida para a LSU 280 desencadeia um aborto. O fornecimento da LRU-extensão aumenta efetivamente a capacidade do perfil a partir do tamanho L1 para o tamanho L2 e de forma associativa, contanto que não haja conflitos com outras CPUs 114 (Figura 1) contra o rastreio de LRU- extensão não exato que provoquem abortos.

[0147] O perfil de armazenamento é limitado pelo tamanho do cache de armazenamento (o cache de armazenamento é discutido em maiores detalhes abaixo) e, assim, implicitamente pelo tamanho de L2 268 e associatividade. Nenhuma ação de LRU-extensão precisa ser executada quando uma linha de cache TX-dirty 252 é enviada para a LRU a partir do L1 240.

Cache de Armazenamento

[0148] Em sistemas do estado da técnica, uma vez que o L1 240 e L2 268 são caches de armazenamento em cache e em memória principal ("store-through"), cada instrução de armazenamento causa um acesso de armazenamento em L3 272; agora com 6 núcleos por L3 272 e desempenho de cada núcleo aprimorado, a taxa de armazenamento para L3 272 (e, em menor extensão, para L2 268) se torna problemática para determinadas cargas de trabalho. De modo a evitar atrasos em formação de filas de armazenamento, uma reunião de cache de armazenamento 264 teve de ser adicionada, que combina armazenamentos para endereços vizinhos antes de enviá-los para L3 272.

[0149] Para desempenho da memória transacional, é aceitável invalidar cada linha TX-dirty do cache 252 a partir de L1 240 quando de aborto de uma transação porque o cache L2 268 é muito próximo (penalidade por falha de L1 240 de 7 ciclos) para trazer de volta as linhas limpas. No entanto, seria inaceitável para o desempenho (e área de silício para rastreio) ter armazenamentos transacionais gravados em L2 268 antes que a transação seja concluída e, então, invalidar todas as linhas "dirty" no cache L2 268 quando de um aborto (ou, pior ainda, em L3 272 compartilhado).

[0150] Os dois problemas de largura de banda de armazenamento e manipulação de armazenamento de memória transacional podem ambos ser abordados com a reunião de cache de armazenamento 264. O cache 232 é uma fila circular de 64 entradas, cada entrada contendo 128 bytes de dados com bits válidos de byte-preciso. Em operação não transacional, quando um armazenamento é recebido a partir da LSU 280, o cache de armazenamento verifica se há uma entrada para o mesmo endereço e, em caso afirmativo, reúne o novo armazenamento na entrada existente. Se não há nenhuma entrada, uma nova entrada é gravada na fila e, se o número de entradas livres cai dentro de um limite, as entradas mais antigas são gravadas novamente nos caches L2 268 e L3 272.

[0151] Quando uma nova transação mais externa começa, todas as entradas existentes no cache de armazenamento são marcadas fechadas, de modo que nenhum novo armazenamento pode ser reunido nas mesmas e o despejo destas entradas para L2 268 e L3 272 é iniciado. Daquele ponto em diante, os armazenamentos transacionais provenientes da LSU 280 STQ 260 são alocados a novas entradas ou são reunidos em entradas transacionais existentes. A regravação destes armazenamentos em L2 268 e L3 272 é bloqueada até que a transação termine com sucesso; deste ponto em diante (pós- transação) os armazenamentos podem continuar a ser reunidos em entradas existentes, até que a próxima transação feche estas entradas novamente.

[0152] O cache de armazenamento é consultado em cada XI exclusiva ou de rebaixar e provoca uma rejeição de XI se a XI se compara a qualquer entrada ativa. Se o núcleo não está completando mais instruções enquanto rejeita continuamente as XIs, a transação é abortada em um determinado limiar para evitar travamentos.

[0153] Os LSU 280 solicita um aborto de transação quando há "overflow" do cache de armazenamento. A LSU 280 detecta esta condição quando tenta enviar um novo armazenamento que não pode ser fundido em uma entrada existente e todo o cache de armazenamento está repleto de armazenamentos provenientes da transação atual. O cache de armazenamento é gerido como um subconjunto de L2 268: enquanto as linhas transacionalmente "dirty" podem ser expulsas de L1 240, elas têm de ficar residentes em L2 268 em toda a transação. O perfil máximo de armazenamento é, portanto, limitado ao tamanho do cache de armazenamento de 64 x 128 bytes e também é limitado pela associatividade de L2 268. Uma vez que L2 268 é associativo em 8 vias e tem 512 linhas, normalmente ele é grande o suficiente para não causar o aborto de uma transação.

[0154] Se há o aborto de uma transação, o cache de armazenamento é notificado e todas as entradas que contêm dados transacionais são invalidadas. O cache de armazenamento também tem uma marca por palavra dupla (8 bytes) se a entrada foi gravada por uma instrução NTSTG - aquelas palavras duplas permanecem válidas através de abortos de transação.

Funções Implementadas em Milicódigo

[0155] Tradicionalmente, os processadores para servidores de mainframe IBM contêm uma camada de firmware denominada milicódigo que desempenha funções complexas, tais como determinadas execuções de instrução CISC, manipulação de interrupção, sincronização de sistema e RAS. O milicódigo inclui instruções dependentes da máquina, bem como instruções da arquitetura de conjunto de instruções (ISA), que são buscadas e executadas a partir da memória de forma similar às instruções de programas de aplicativos e o sistema operacional (OS). O firmware reside em uma área restrita da memória principal que os programas cliente não podem acessar. Quando o hardware detecta uma situação que precisa para invocar o milicódigo, a unidade de busca de instruções 204 troca para o "modo de milicódigo" e começa a busca no local apropriado na área de memória do milicódigo. O milicódigo pode ser obtido e executado da mesma maneira como as instruções do conjunto de instruções (ISA) e pode incluir instruções ISA.

[0156] Para a memória transacional, o milicódigo está envolvido em várias situações complexas. Cada aborto de transação invoca uma sub-rotina de milicódigo dedicada para realizar as operações necessárias para aborto. O milicódigo de aborto de transação começa por leitura de registros de finalidade específica (Special Purpose Registers - SPRs) que contêm a razão interna para o aberto em hardware, razões de exceção potenciais e o endereço de instrução abortado os quais, então, o milicódigo usa para armazenar um TDB se for especificado. O texto de instrução TBEGIN é carregado a partir de um SPR para obter a máscara de salvar GR, o que é necessário para que o milicódigo saiba quais GRs 238 restaurar.

[0157] A CPU 114 (Figura 2) dá suporte a uma instrução de milicódigo especial para leitura apenas do backup de GRs 224 e copiá-los para os GRs 228 principais. O endereço de instrução TBEGIN também é carregado a partir de um SPR para definir o novo endereço de instrução na PSW para continuar a execução após TBEGIN, uma vez que a sub-rotina de aborto de milicódigo termina. Esta PSW pode depois ser salva como PSW de programa antiga no caso onde o aborto é causado por uma interrupção de programa não filtrada.

[0158] A instrução TABORT pode ser implementada em milicódigo; quando a IDU 208 decodifica TABORT, ela instrui à unidade de busca de instrução a ramificar em milicódigo de TABORT, a partir do qual o milicódigo se ramifica para a sub-rotina de aborto em comum.

[0159] A instrução Extrair Profundidade de Agrupamento de Transação (ETND) também pode estar em milicódigo, uma vez que ela não é crítica para o desempenho; o milicódigo carrega a profundidade de agrupamento atual de um registro de hardware especial e coloca-o em um GR 228. A instrução PPA está em milicódigo; ela executa o atraso ideal com base na contagem de abortos atual fornecida pelo software como um operando para a PPA e também com base em outro estado interno do hardware.

[0160] Para transações restritas, o milicódigo pode manter o rastreio do número de abortos. O contador é redefinido para 0 quando de conclusão de TEND com sucesso ou se uma interrupção no OS ocorre (uma vez que não se sabe se ou quando o OS retomará ao programa). Dependendo da contagem de abortos atual, o milicódigo pode invocar determinados mecanismos para melhorar as chances de sucesso para a tentativa de transação subsequente. Os mecanismos envolvem, por exemplo, aumentar sucessivamente atrasos aleatórios entre as tentativas e reduzir a quantidade de execução especulativa para evitar a ocorrência de abortos causados por acessos especulativos aos dados que a transação não está usando realmente. Como último recurso, o milicódigo pode transmitir para outras CPUs 114 (Figura 2) para interromper todo o trabalho conflitante e repetir a transação local antes de liberar as outras CPUs 114 para continuar o processamento normal. Múltiplas CPUs 114 devem ser coordenadas para não causar bloqueios, de modo alguma serialização entre casos de milicódigo em diferentes CPUs 114 é necessária.

[0161] A Figura 4 ilustra um sistema de computador 300 de acordo com uma concretização. A Figura 4 está configurada para implementar recursos discutidos nas Figuras 1-3 e 5-18. O computador 300 compreende múltiplos processadores designados como processador 112a (CPU 1) e 112b (CPU 2) (juntamente com processadores adicionais não mostrados) em comunicação com uma memória 310 por meio de um subsistema de cache hierárquico, em que cargas transacionais, por parte do processador, são monitoradas em um cache de um subsistema de cache hierárquico . O sistema de computador 300 mostrado na Figura 4 tem os mesmos elementos que o sistema de computador 100 mostrado na Figura 1 e os mesmos numerais de referência, mas cada elemento na Figura 1 não é mostrado na Figura 4.

[0162] O sistema de computador 300 pode gerenciar uma solicitação, por exemplo, uma interrupção, apresentada a um ou mais processadores que estão disponíveis para transações atualmente em processamento. Em um exemplo, um processador solicitante (por exemplo, uma CPU (112a)) pode selecionar um processador receptor/remoto (por exemplo, CPU 2 (112b)) e enviar uma solicitação para o processador remoto selecionado. Em um exemplo, o sistema de computador é um sistema ou ambiente de execução transacional (TX), por exemplo, incluindo uma CPU ou processador capaz de executar uma transação. Cada transação é, respectivamente, mostrada como instruções de transação 320a e 320b que, respectivamente, são executadas em processadores 112a e 112b. Cada processador 112a e 112b tem seu próprio registro 334a e 334b, respectivamente.

[0163] Cada cache de dados 118a e 118b pode, respectivamente, incluir seu próprio cache L1 e L2. A memória do computador é genericamente representada pela memória 310, a qual pode incluir memória cache de nível mais elevado nas CPUs designada como CPUs TX, isto é, os processadores 112a e 112b. Cada processador 112a e 112b tem sua própria tabela de rastreio de interferência de transação local designada como tabelas 1350a e 1350b, respectivamente. As tabelas 1350a e 1350b podem ser armazenadas, respectivamente, no cache de dados 118a, 118b, registros 334a, 334b e/ou na memória 310. A memória 310 também pode incluir um bloco diagnóstico de transação 350 para armazenar informação diagnóstica sobre transações, o que pode incluir a informação de interferência de transação (juntamente com estatística) armazenada nas tabelas 1350a e 1350b, conforme adicionalmente discutido aqui .

[0164] O sistema de computador 300 é uma representação de um ambiente de transação (TX) que envia, recebe e processa solicitações e respostas de acordo com concretizações. Observe que vários exemplos são fornecidos nos quais o processador 112a (CPU 1) está ilustrado como o processador solicitante que gera e envia uma solicitação para o processador 112b (CPU 2) que está ilustrado como o processador receptor/remoto que recebe a solicitação. Deve ser entendido que esta designação é para fins de explicação, uma vez que qualquer processador pode enviar e receber solicitações de dados, conforme entendido por aqueles versados na técnica.

[0165] A Figura 5 ilustra um protocolo de solicitação e resposta exemplificativo. A solicitação de protocolo pode ser referida como um protocolo de multiprocessador mainframe e o protocolo pode ser através de uma interconexão com base em barramento ou com base em switch. O protocolo pode ser de sinalização totalmente paralela ("bus snooping"), pacotes seriais ou uma combinação dos mesmos.

[0166] Como um exemplo, uma solicitação 505 por dados pode ser enviada a partir de uma CPU (112a) para a CPU 2 (112b) . A solicitação 505 inclui um campo de tipo 506 que diz qual tipo de solicitação está sendo enviada (por exemplo, solicitação de leitura compartilhada ou leitura exclusiva - ou Read For Ownership - de acordo com o protocolo de coerência MESI conhecido ou solicitações de protocolo de acordo com outros de tais protocolos) e um campo de marcador 507 que identifica o processador particular (por exemplo, CPU 1) que enviou a solicitação e, opcionalmente, o processador receptor, por exemplo, CPU 2 para a qual a solicitação está sendo enviada e, opcionalmente, se múltiplas solicitações podem ser simultaneamente processadas, uma solicitação de ID específica para identificar exclusivamente cada solicitação. A solicitação 505 também inclui um campo de acesso 508 que identifica o tipo de acesso que está sendo solicitado pelo processador solicitante (CPU 1) e um campo de endereço 509. O campo de endereço 509 identifica o endereço de memória da linha de cache ou palavra de memória que está sendo solicitada. A solicitação de protocolo 505 pode incluir um campo de correção de erro 510 que contém um código de detecção de erro e/ou correção usado, por exemplo, verificação de redundância cíclica (Cyclic Redundancy Check - CRC), bits de paridade ou ECC.

[0167] Uma resposta 515 pode ser enviada de volta a partir do processador receptor (CPU 2) para o processador solicitante (CPU 1). A resposta 515 inclui o tipo de campo 516 que indica o tipo de resposta, tal como uma resposta de leitura (READ RESPONSE) e um campo de marcador 517. O campo de marcador 517 pode ser o mesmo marcador que o campo de marcador 507 da solicitação original 505 e/ou o campo de marcador 517 pode incluir o endereço de memória solicitado da linha de cache. A resposta 515 inclui um campo de dados 518 que são os dados solicitados os quais foram solicitados pelo processador solicitante (CPU 1). Algumas respostas de protocolo podem não incluir transferências de dados (por exemplo, solicitações de protocolos para escalar a posse de compartilhada para a propriedade exclusiva de uma linha) e podem incluir apenas um reconhecimento de que o processamento foi realizado. Um campo de correção de erro 519 é incluído na resposta 515.

[0168] Em algumas concretizações, a sinalização para solicitações de protocolo pode ocorrer em paralelo sobre uma pluralidade de linhas de bit e quaisquer campos não usados que possam corresponder a linhas que não têm qualquer valor definido pelo protocolo são ajustados para um valor predefinido ou, de outro modo, não são considerados uma parte de uma mensagem de protocolo. Em algumas concretizações, a solicitação de protocolo pode ser transmitida em múltiplos "beats", por exemplo, grupos sucessivos de bits que representam, em sua totalidade, uma mensagem de protocolo. Em ainda outras concretizações, as solicitações de protocolo podem ser transmitidas em bits de forma serial. Em protocolos transmitidos em múltiplos "beats" ou de forma serial, algumas mensagens podem consistir em mais ciclos de sinalização por barramento do que outras solicitações de protocolo.

[0169] A Figura 6 ilustra outro exemplo de solicitação de protocolo. Muitos protocolos adquirem acesso exclusivo via RFO (Read For Ownership) ou solicitações de leitura exclusiva para operações de gravação, enquanto que outros protocolos podem gravar diretamente (limitado). Como um exemplo, uma solicitação 605 exemplificativa para gravar dados pode ser enviada a partir de uma CPU (112a) para a CPU 2 (112b). A solicitação 605 inclui o campo de tipo 506 que identifica o tipo de solicitação que está sendo enviada (por exemplo, gravação) e o campo de marcador 507 que identifica o processador particular (por exemplo, CPU 1) que enviou a solicitação de gravação e, opcionalmente, o processador receptor, por exemplo, CPU 2 para o qual a solicitação está sendo enviada e um solicitante particular. A solicitação 605 também inclui um campo de dados 504 que transmite os dados que estão sendo gravados pelo processador solicitante (CPU 1) e o campo de endereço 509. O campo de endereço 509 identifica o endereço de memória da linha de cache ou o endereço da linha que está sendo gravada. O protocolo de solicitação 6 05 pode incluir o campo de correção de erro 510 que contém um código de detecção de erro e/ou correção usado, por exemplo, verificação de redundância cíclica (CRC), bits de paridade ou ECC.

[0170] Em resposta a uma solicitação de gravação, geralmente não há resposta, uma vez que não é necessário obter dados para acesso exclusivo antes de efetuar uma gravação .

[0171] A Figura 7 é um fluxograma 700 de geração de solicitação de protocolo pelo processador (por exemplo, CPU 1 (112a)) que faz uma solicitação de dados de acordo com uma concretização. Um processador (por exemplo, CPU 1) faz uma solicitação por dados de memória no bloco 705. O processador (por exemplo, CPU 1 (112a)) verifica se os dados solicitados estão em seu próprio cache local (por exemplo, o cache L1 no cache de dados 118a) no bloco 710. Quando os dados estão disponíveis no próprio cache local do processador, o fluxo procede para o bloco 735. Quando o dados não estão disponíveis em caches locais do processador (CPU 1), o processador gera a solicitação XI (interrogação cruzada) para solicitar os dados desejados a partir de outros processadores (tal como a CPU 2 (112b)) no bloco 715. O processador solicitante (CPU 1) envia a solicitação XI por dados para o processador receptor (CPU 2) por meio de interconexão 122 no bloco 720 e o processador solicitante (CPU 1) recebe a resposta XI com os dados (solicitados) a partir do processador receptor (CPU 2) no bloco 725. O processador solicitante (CPU 1) coloca os dados em seus caches locais (por exemplo, cache L1, L2) no cache de dados 118a no bloco 730. O processador solicitante (CPU 1) obtém os dados a partir de seu cache local 118a através do cache de instruções 116a no bloco 735. O cache de instruções 116a do processador solicitante fornece os dados para os circuitos da CPU 1 para processamento no bloco 740.

[0172] Em uma concretização e de acordo com um protocolo de cache em comum (por exemplo, o protocolo MESI conhecido), quando o processador acessa os dados para leitura e os dados não estão disponíveis, uma XI é gerada para leitura compartilhada em que os dados são obtidos de forma compartilhada, de modo que múltiplas CPUs 112a, 112b podem ter uma cópia dos dados em um cache e em que cada CPU pode processar um acesso de leitura de memória que corresponde aos dados. Os dados recebidos são colocados no cache e marcados para acesso compartilhado e o processador pode executar acessos de leitura a partir da cópia responsiva a uma operação de leitura de memória. Quando o processador acessa dados para gravação e os dados não estão disponíveis no estado exclusivo, uma XI é gerada para leitura exclusiva, em que os dados são obtidos de uma forma exclusiva, de modo que apenas um único processador (por exemplo, CPU 112a) pode ter uma cópia dos dados em um cache. Os dados recebidos são colocados no cache e marcados para acesso exclusivo e o processador pode atualizar a cópia responsiva às operações de memória de gravação. Em uma concretização, quando os dados estão presentes de modo compartilhado e um acesso de gravação é recebido, uma leitura XI exclusiva é gerada. Em pelo menos uma concretização, isto é indicado como um solicitação de leitura exclusiva distinta em que não existem dados recebidos como parte da resposta. Em uma concretização, quando uma resposta foi recebida, os dados cache são marcados para acesso exclusivo.

[0173] A Figura 8 ilustra um fluxograma 800 exemplificativo de gerenciamento de solicitação pelo processador receptor/remoto (por exemplo, CPU 2 (112b)) que recebe a solicitação e envia uma resposta de acordo com uma concretização.

[0174] O processador remoto (CPU 2) recebe a solicitação XI de dados do processador solicitante (CPU 1) no bloco 805. No bloco 810, o processador remoto (2 CPU) verifica se uma interferência é detectada ao verificar se o processador remoto está processando uma transação que atualmente precisa dos dados solicitados (no cache local do processador remoto). Quando o processador remoto (CPU 2 (112b)) determina que o processador remoto está usando os dados solicitados pelo processador solicitante (CPU 1 (112a)), no bloco 810, o processador remoto determina (SIM) que uma interferência é detectada e o processador remoto (CPU 2) aborta a transação local que está ocorrendo no processador remoto (CPU 2) no bloco 815. Uma vez que a transação local é abortada no processador remoto (CPU 2), o processador remoto transmite os dados com a resposta de leitura (READ RESPONSE) para o processador solicitante (CPU 1) no bloco 820. O processador remoto (CPU 2) muda o estado dos dados e, opcionalmente, purga dados a partir de seus caches locais, se necessário, no bloco 825. Em uma concretização, uma mudança de estado de cache pode incluir liberação de dados a partir de pelo menos um de um conjunto de leitura ou gravação quando uma transação foi abortada. Em uma concretização, uma mudança de estado de cache pode incluir mudança do estado de uma linha de cache no diretório de cache, por exemplo, definindo o estado para um de compartilhado, exclusivo, inválido e assim por diante, de acordo com um protocolo de cache, tal como o protocolo MESI conhecido. O processador remoto (CPU 1) inicia o processamento de falha de transação no bloco 830 e o fluxo termina. Quando o processador remoto (CPU 2 (112b)) determina que o processador remoto não está usando os dados solicitados pelo processador solicitante (CPU 1 (112a)), no bloco 810, o processador remoto determina que nenhuma interferência é detectada e o processador remoto (CPU 2) transmite dados com a resposta de leitura (READ RESPONSE) no bloco 835. O processador remoto (CPU 2) muda o estado dos dados e, opcionalmente, purga dados a partir de caches locais, se necessário, no bloco 840 e o fluxo termina.

[0175] A Figura 9 é um fluxograma 900 que ilustra o gerenciamento de transações por um processador de acordo com uma concretização. No bloco 905, a transação começa a ser executada no processador (por exemplo, CPU 1 ou CPU 2). Na Figura 9, observe que cada processador (CPU 1 e CPU 2) pode estar executando essas ações, ou seja, as transações podem ser processadas tanto por 112a, 112b e assim por diante. O processador executa as instruções dentro da transação no bloco 910 (por exemplo, conforme discutido na Figura 7). O processador realiza ações de protocolo em resposta às instruções de transação no bloco 915. O processador verifica se há interferência (com o uso dos dados) que requer que o processador aborte a transação em 920. Quando o processador determina (SIM) que há interferência detectada, o processador aborta sua própria transação (nos dados) no bloco 925 e o fluxo prossegue para o bloco 935. Quando o processador determina (NÃO) que nenhuma interferência é detectada, o processador conclui (as instruções) sua transação no bloco 930. O processador grava as informações de transação (tal como bloco de diagnóstico de transação (TBD)) em um registro no bloco 935.

[0176] De acordo com concretizações, o protocolo de coerência é estendido para incluir informações adicionais sobre o estado da transação. A Figura 10 ilustra a solicitação de protocolo 505 e uma nova resposta de protocolo 1005 de acordo com as concretizações. Conforme mostrado na Figura 10, alguns campos da solicitação 505 são idênticos aos campos discutidos na Figura 5. Conforme mencionado acima, a solicitação 505 inclui o campo de tipo 506 que identifica o tipo de solicitação que está sendo enviada (por exemplo, LEITURA) e o campo de marcador 507 que identifica o processador particular (por exemplo, CPU 1) que enviou a solicitação (e, opcionalmente, o processador receptor/remoto, por exemplo, CPU 2, para o qual a solicitação está sendo enviada e um número de solicitação). A solicitação 505 também inclui o campo de acesso 508 que informa o tipo de acesso que está sendo solicitado pelo processador solicitante (CPU 1) e o campo de endereço 509 que diz o endereço de memória da linha de cache ou linha de endereço que está sendo solicitada. A solicitação de protocolo 505 inclui o campo de correção de erro 510 que informa o tipo de código de erro usado, tal como verificação de redundância cíclica (CRC).

[0177] A nova resposta 1005 inclui os campos da resposta 515 (na Figura 5) juntamente com um campo de estado de abortar transação adicional 1010. A resposta 1005 pode ser enviada de volta a partir do processador receptor/remoto (CPU 2) para o processador solicitante (CPU 1). A resposta 515 inclui o campo de tipo 516 que indica o tipo de resposta, tal como uma resposta de leitura (READ RESPONSE) e o campo de marcador 517 que indica o endereço de memória requerida da linha de cache (o qual pode ser o mesmo marcador que o campo de marcador 507 da solicitação original 505). A resposta 515 inclui o campo de dados 518 que são os dados solicitados que foram solicitados pelo processador solicitante (CPU 1) . Se os dados não são transmitidos com uma resposta de protocolo, então, o campo de dados 518 está vazio ou não está presente. O campo de detecção/correção de erro 519 está incluído na resposta 1005.

[0178] Além disso, a nova resposta de protocolo 1005 (enviada pelo processador remoto CPU 2 para o processador solicitante CPU 1) tem o campo de estado de abortar transação 1010. O campo de estado de abortar transação 1010 inclui uma ou mais das seguintes informações sobre a transação anteriormente em execução no processador receptor/remoto (CPU 2) antes de ser abortada: 1) Se a solicitação 505 (a partir do processador solicitante (CPU 1) causou e/ou não causou a reversão (ou seja, aborto); 2) A prioridade desta transação que estava sendo executada no processador receptor/remoto (CPU 2) antes de ser abortada; 3) Quantas instruções, operações de memória e/ou outra medida de trabalho haviam sido realizadas pela transação anteriormente em execução no processador receptor/remoto (CPU 2) antes que a transação fosse abortada; 4) Identificar a transação (por exemplo, token, endereço de TBEGIN e/ou outros meios de identificação da transação abortada) anteriormente em execução no processador remoto (CPU 2).

[0179] Além disso, o campo de estado de abortar transação 1010 diz quais dados foram obtidos pela transação (anteriormente em execução no processador receptor/remoto) que teve de ser abortada, diz o endereço da transação e diz o custo de abortar a transação (o qual poderia ser 3 ciclos de "clock" ou 20.000 ciclos de "clock" de trabalho).

[0180] Quando um processador (por exemplo, processador receptor CPU 2 na situação exemplificativa) está em execução transacional, uma solicitação de coerência pode causar a execução que faz a transação ser abortada, por exemplo, porque os dados são parte da o conjunto de leitura ou gravação da transação, e um conflito (ou seja, a interferência) é detectado.

[0181] De acordo com uma concretização, a Figura 11 ilustra a solicitação 605 (gravação) na Figura 6 para gravar dados (enviados a partir do processador solicitante CPU 1 (112a) para o processador receptor/remoto CPU 2 (112 b)) e uma nova resposta 1105 é enviada de volta para o processador solicitante CPU 1 (112a) pelo processador remoto CPU 2 ( 112b). a Figura 11 é um solicitação de protocolo e resposta exemplificativas que adiciona informação de transação na resposta, de acordo com uma concretização, ao introduzir uma nova resposta de protocolo a uma transação que anteriormente não requeria uma resposta de protocolo, de modo a transmitir a informação de interferência de transação/abortar para o originador da solicitação. Em pelo menos uma concretização, a resposta de protocolo que é transmitida com a única finalidade de fornecer um estado de abortar transação é opcional e pode ser suprimida em alguns modos, em resposta à configuração de bits, em resposta a um congestionamento de barramento e/ou por outras razões. Em tal situação, quando nenhuma resposta é recebida, nenhum estado de abortar transação é reportado que corresponde a um solicitação para a qual não foi recebida nenhuma resposta. Em pelo menos uma concretização, uma ausência de uma ou mais respostas pode ser reportada. Conforme observado acima, a solicitação 605 inclui o campo de tipo 506 que informa o tipo de solicitação que está sendo enviada (por exemplo, gravação) e o campo de marcador 507 que identifica o processador particular (por exemplo, CPU 1) que enviou a solicitação de gravação (e o processador receptor, por exemplo, CPU 2, para o qual a solicitação está sendo enviada). A solicitação 605 também inclui o campo de acesso 508 que informa o tipo de acesso que está sendo solicitado pelo processador solicitante (CPU 1) e o campo de endereço 509. O campo de endereço 509 indica o endereço de memória da linha de cache ou linha de endereço na qual a gravação está sendo solicitada. O protocolo de solicitação 605 pode incluir o campo de detecção e/ou correção de erro 510 com um código de correção/detecção de erro, tal como códigos de bits de paridade, ECC ou verificação de redundância cíclica (CRC).

[0182] Em resposta à solicitação de gravação 605, a nova resposta 1105 (para a solicitação de gravação) agora inclui o campo de estado abortar transação 1010 discutido aqui. A nova resposta 1105 inclui os campos de resposta 1005 (na Figura 10). A resposta 1105 pode ser enviada de volta do processador receptor/remoto (CPU 2) para o processador solicitante (CPU 1). A resposta 1105 inclui o tipo de campo 516 que indica o tipo de resposta, tal como uma resposta de gravação (WRITE RESPONSE) e o campo de marcador 517 que indica o endereço de memória solicitada da linha de cache (o qual pode ser o mesmo marcador que o campo de marcador 507 da solicitação 505 original para identificar a solicitação à qual a resposta corresponde). A resposta 515 pode incluir um campo de dados 518 que são os dados solicitados que foram solicitados pelo processador solicitante (CPU 1). Uma vez que nenhum dado é proveniente do cache (local) do processador receptor/remoto (CPU 2), então, o campo de dados 518 está vazio. O campo de correção de erro 519 está incluído na resposta 1005.

[0183] Conforme discutido aqui, o campo de estado abortar transação 1010 fornece o estado da transação (anteriormente em execução no processador receptor/remoto (CPU 2)) que foi necessária abortar em virtude da solicitação de gravação 605 (a partir do processador solicitante (CPU 1) ) .

[0184] Embora aprimoramentos de protocolo de acordo com a presente invenção tenham sido descritos, em uma concretização exemplificativa, em conjunto com a adição de um campo de protocolo que corresponde a um estado de abortar transação e informações associadas a uma resposta de leitura existente e, em outra concretização exemplificativa, em conjunto com a adição de uma resposta de protocolo que corresponde a uma solicitação de gravação de protocolo que não tem uma resposta de protocolo de acordo com o estado da técnica, de modo a transmitir pelo menos um campo de protocolo que corresponde a um estado de abortar transação e informações associadas e identificar uma solicitação de gravação correspondente, aqueles versados na técnica serão capazes de aplicar os ensinamentos contidos aqui a outros formatos de XI, formatos de protocolo, tipos de solicitações, protocolos de coerência e assim por diante.

[0185] De acordo com uma concretização, a Figura 12 é um fluxograma 1200 que ilustra o gerenciamento de solicitação de coerência, por exemplo, pelo processador receptor/remoto CPU 2 (112b) que recebe a solicitação do processador solicitante CPU 1 (112a). A Figura 12 inclui os blocos da Figura 8, juntamente com os novos blocos (modificados) 1205 e 1210 que compreendem transmissão do estado de abortar transação (no campo de abortar transação 1010), como parte de respostas de protocolo.

[0186] Na Figura 12, o gerenciamento de solicitação pelo processador receptor/remoto (por exemplo, CPU 2 (112b)) recebe a solicitação de acordo com uma concretização. O processador remoto (CPU 2) recebe a solicitação XI (por exemplo, a solicitação 505 e/ou solicitação 605) por dados a partir do processador solicitante (CPU 1) no bloco 805. No bloco 810, o processador remoto (CPU 2) verifica se uma interferência é detectada ao verificar se o processador remoto está processando uma transação que faz referência a dados de forma incompatível com a solicitação recebida, por exemplo, solicitação 505 e 605. Por exemplo, em uma concretização exemplificativa, uma solicitação de leitura compartilhada é compatível com uma referência a dados em uma conjunto de leitura de transação, mas uma solicitação de gravação não é. Além disso, uma solicitação de leitura exclusiva, escalonamento de leitura (ou seja, mudar de compartilhado para exclusivo) ou gravação não é compatível com os mesmos dados tomados como referência em um conjunto de leitura ou gravação de transação. Quando o processador remoto (CPU 2 (112b)) determina que o processador remoto (em si) está atualmente usando os dados solicitados pelo processador solicitante (CPU 1 (112a)) no bloco 810, o processador remoto determina (SIM) que a interferência é detectada e o processador remoto (CPU 2) aborta a transação local que está ocorrendo no processador remoto (CPU 2) no bloco 815. Uma vez que a transação local é abortada no processador remoto (CPU 2), o processador remoto transmite os dados com a resposta de leitura (READ RESPONSE) para o processador solicitante (CPU 1), juntamente com o campo de estado de transação 1010 (que notifica que a solicitação provocou um aborto da transação (anteriormente em execução) no processador receptor/remoto (CPU 2), a fim de cumprir a solicitação) no bloco 1 205. Em outra concretização, ele pode reconhecer uma solicitação de gravação recebida com uma resposta de gravação 1105. Nos sistemas do estado da técnica, nenhum campo de estado de transação 1010 seria incluído na resposta (RESPONSE) enviada a partir do CPU remota 2 (que estava anteriormente executando sua própria transação agora abortada) de volta para a CPU solicitante 1 (que enviou a solicitação 505 e/ou 605).O processador remoto (CPU 2) muda o estado dos dados e, opcionalmente, purga a partir de seus caches locais, se necessário, no bloco 825. O processador remoto (CPU 1) inicia o processamento da falha de transação no bloco 830 e o fluxo termina. Quando o processador remoto (CPU 2 (112b)) determina que o processador remoto não está usando os dados solicitados pelo processador solicitante (CPU 1 (112a)) no bloco 810, o processador remoto determina que nenhuma interferência é detectada e o processador remoto (CPU 2) transmite os dados com a resposta de leitura (READ RESPONSE), juntamente com o campo de estado de transação 1010 (que indica que a solicitação não fez com que a transação fosse abortada) no bloco 1210. O processador remoto (CPU 2) muda o estado dos dados e, opcionalmente, limpa os dados do cache local, se necessário, no bloco 840 e o fluxo termina.

[0187] A Figura 13 é um fluxograma que ilustra a origem da solicitação de protocolo 1300 e processamento pelo processador solicitante (CPU 1 (112a)) de acordo com uma concretização. A Figura 13 inclui os blocos discutidos acima na Figura 7 e a discussão da Figura 7 não será repetida. Adicionalmente, o fluxograma 1300 inclui novos blocos 1305 e 1310. Por exemplo, o processador solicitante (CPU 1) recebe a resposta XI com dados a partir do processador remoto (CPU 2) (bloco 725), juntamente com o novo campo de estado de abortar transação 1010 no bloco 1305. O processador solicitante (CPU 1) coloca os dados em caches locais (tais como os caches L1 e/ou L2) no bloco 730. No bloco 1310, o processador solicitante (CPU 1) adiciona o estado recebido (por exemplo, informação no campo de estado de transação 1010) a uma tabela de rastreio de interferência de transação local 1350 no cache de dados 118a (e/ou memória 310) . A tabela de rastreio de interferência de transação local 1350 pode ser um local de armazenamento que mantém o controle de interferência quando o processador solicitante (CPU 1) causa a interferência (resultando em abortar transação no processador remoto (CPU 2)) e a tabela de rastreio de interferência de transação local 1350 pode incluir um log desta informação. A tabela de rastreio de interferência de transação local (armazenamento) 1350 inclui estatísticas de incremento e estado da transação atual. O aumento das estatísticas de incremento para cada aborto de transação (reportado de volta para o processador receptor (CPU 1) e as estatísticas de incremento podem ser separadas em solicitações compartilhadas/exclusivas (R/W) e solicitações agregadas. A tabela de rastreio de interferência de transação local 1350 pode incluir um contador que aumenta para cada transação abortada causada pelo processador solicitante (CPU 1) e para cada vez que nenhuma transação é abortada no processador solicitante (CPU 1) . Em algumas modalidades, o estado de abortar transação recebido em conjunto com o bloco 1310 também pode ser agregado em uma unidade de monitoramento de desempenho, uma unidade de tempo de execução de instrumentação e/ou outra lógica de rastreio de desempenho, de modo a tornar a informação disponível para otimizadores dinâmicos, compiladores "just in time" (JIT) ou para sintonia de desempenho por programadores. As informações podem ser gravadas ao registrar em armazenamento em estruturas dirigidas ao monitoramento de desempenho e/ou ao aumentar as notificações, por exemplo, as ramificações com base em eventos PMU, de acordo com o Poder ISA™, ou exceções. Os relatórios podem incluir a natureza da interferência, identificação da interferência e/ou transação que sofreu a interferência, IDs de processador, endereços que são objeto de tal interferência e assim por diante.

[0188] Conforme discutido aqui, os protocolos de coerência usam um número de bits - bits de endereço, dados e estado e controle. Estes dados são usados para emitir uma solicitação de dados e indicar sua propriedade (por exemplo, compartilhado, exclusivo) e estado (por exemplo, "dirty", limpo). Um ou mais bits adicionais (para o campo de estado de abortar transação 1010) são adicionados para indicar que uma solicitação fez com que uma transação fosse abortada e/ou pode fazer com que uma transação seja abortada. Por exemplo, um bit de estado (campo de estado de abortar transação 1010) indica que os dados solicitados causaram um conflito para a execução de transações quando os dados foram fornecidos pelo processador remoto (CPU 1). Conforme observado, a resposta à solicitação pode voltar com uma indicação de que uma transação está em andamento e que a solicitação fez com que uma transação fosse abortada.

[0189] Em uma concretização, métricas adicionais, tais como o número de instruções em uma transação abortada, são transmitidas no campo de estado de abortar transação 1010. Em uma concretização, as indicações são usadas para determinar um tempo de espera, por exemplo, em relação à reinicialização de uma transação no caso em que a transação vencedora é depois abortada e é reiniciada, para evitar situações de "livelock". O processador solicitante (CPU 1) também pode desacelerar (reduzir) sua taxa de solicitações em resposta ao aborto de muitas transações remotas para aumentar o rendimento geral do sistema, quando o processador que fez a solicitação (CPU 1) determina que o processador solicitante causou muitos abortos (por exemplo, uma quantidade predefinida) no processador receptor/remoto (CPU 2) ao verificar o campo de estado de abortar transação local 1010.

[0190] Em ainda outra concretização, tais notificações (no campo de estado de abortar transação 1010) são reunidos em logs e/ou notificadas através de um mecanismo de notificação (por exemplo, uma exceção) para um componente de reotimização dinâmica; o componente de reotimização dinâmica pode re-otimizar dinamicamente o código para reduzir a interferência e/ou gerar um código alternativo para usar bloqueios em lugar de transações.

[0191] Agora, os blocos da Figura 9 estão incluídos na Figura 14, mas a discussão não será repetida. A Figura 14 também inclui uma modificação na Figura 9. A Figura 14 é um fluxograma 1400 que ilustra o gerenciamento de transação por um processador de acordo com uma concretização. Pode-se supor que o processador é o processador solicitante (CPU 1) . A Figura 14 inclui os blocos da Figura 9, juntamente com o bloco 1405. No bloco 1405, o processador solicitante (CPU 1) grava a informação de transação (como o bloco de diagnóstico de transação (TBD)), incluindo as estatísticas de interferência de transação (obtidas a partir do novo campo de estado de abortar transação 1010 e armazenadas em uma tabela de armazenamento de rastreio de interferência de transação local 1350a) no registro 334, cache 118a e/ou memória 310 no bloco 1405. Em uma concretização, quando a transação é concluída, a transação pode incluir uma indicação se ela fez com que uma ou mais transações fossem abortadas como parte de um código de resultados, por exemplo, um registro de resultados, registro de condição de resultados e assim por diante (por exemplo, nos registros 334a, 334b). Em uma concretização, quando a transação define um estado de resultados em um ou mais registros (por exemplo, registros 334a, 334b) e/ou memória local, os um ou mais registros (por exemplo, registros 334a, 334b) e/ou locais de memória (por exemplo, memória 310, cache 118a, 118b) podem incluir o número de transações que sofreram interferência que foram abortadas para fornecer dados para a transação, a natureza da interferência (solicitação de leitura com conjunto de gravação ou solicitação de gravação com leitura ou gravação e assim por diante) . Em uma concretização, a informação assim armazenada pode incluir informações específicas sobre cada uma das transações e incluir um modo para identificar um processador no qual a interferência ocorreu, uma transação que foi abortada (por exemplo, ao especificar o endereço de início da transação XBEGIN ou TBEGIN, um token, uma ID de transação e assim por diante), uma medida de trabalho que foi realizada por esta transação antes que ela fosse abortada e assim por diante. Em uma concretização, quando um bloco de diagnóstico de transação do estado da técnica é estendido, de acordo com a presente descrição, para ter campos adicionais que correspondem a interferências e o estado de abortar transação, a informação armazenada em um ou mais locais na memória corresponde a locais na memória de um bloco de diagnóstico de transação (TDB) de acordo, por exemplo, com a arquitetura z/Architecture (incluída aqui por referência) e para os campos de um bloco de diagnóstico de transação de acordo com a presente descrição, os campos que correspondem às informações transmitidas individualmente por campos de protocolo recentemente introduzidos e/ou pela informação agregada a partir de uma pluralidade de tais campos. Em outra concretização, a informação armazenada em registros e/ou memória local é fornecida como distinta, separada e independente de um TDB do estado da técnica.

[0192] No bloco 1405, o processador solicitante (CPU 1) é configurado para fornecer as estatísticas de interferência através da unidade de monitoramento de desempenho e/ou unidade de tempo de execução de instrumentação para o programador e fornecer informações de interferência para o firmware, milicódigo, etc. Em milicódigo, o código de milicódigo pode usar a informação sobre estatística de interferência para evitar "livelock" e/ou usar a informação sobre estatística de interferência para otimizar a reinicialização da transação. Em um aplicativo, o aplicativo pode usar a informação sobre estatística de interferência para evitar "livelock" e otimizar a reinicialização da transação.

[0193] De acordo com uma concretização, o código exemplificativo é fornecido abaixo para fins de explicação.

[0194] O seguinte pseudocódigo (executado nos processadores 112a, 112b) fornece uma forma de realizar a otimização de reinicialização de transação (seja de forma transparente em milicódigo e/ou por código integrado em um aplicativo em execução no processador), de modo a reiniciar uma transação quando a transação foi abortada e otimizada, em particular, para evitar situações de "livelock". O código exemplificativo usa a informação armazenada no TDB de forma exemplificativa, no entanto, aqueles versados na técnica serão capazes de usar a informação obtida a partir de, incluindo, porém sem limitações, locais na memória (por exemplo, memória 310), registros 334a, 334b, códigos de estado e/ou uma unidade de monitoramento de desempenho, unidade de tempo de execução de instrumentação e assim por diante: SE (esta operação foi abortada) { ACESSAR informações em TDB SE (esta transação abortou outra transação) { travamento mútuo detectado <= VERDADEIRO; SE (travamento mútuo detectado) evitar_livelock (); // tomar medidas para evitar livelock, // por exemplo, diminuir prioridade da transação atual; // esperar por um período de recuo; // sincronizar usando bloqueios; // e assim por diante } }

[0195] De acordo com o código exemplificativo, o código de reiniciar transação inclui verificações se ela foi abortada em si e, por sua vez, outra transação foi abortada. Em uma concretização, um possível "livelock" é diagnosticado imediatamente. Em outra concretização, um teste é realizado (não mostrado) se a transação atual e a transação que sofreu a interferência fazem parte de um gráfico de interferência cíclica (isto é, cada transação está, direta ou indiretamente abortando a outra transação). Em uma concretização, quando um travamento mútuo é diagnosticado, medidas para evitar interferências são tomadas. Em uma concretização, quando um travamento mútuo é diagnosticado, medidas para evitar "livelock" são tomadas. Em uma concretização, as medidas para evitar interferências são invocadas pela chamada de uma função evitar_livelock (). Em algumas concretizações, estas medidas podem incluir, porém sem limitações, um ou mais de diminuir prioridade da transação atual; esperar por um período de recuo; sincronizar usando bloqueios; e assim por diante.

[0196] Em outra concretização exemplificativa, o pseudocódigo a seguir constitui uma forma de realizar a otimização de reinicialização de transação (seja de forma transparente em milicódigo ou por código integrado em um aplicativo em execução no processador), a fim de reiniciar uma transação quando ela foi abortada e otimizada, em particular para evitar situações de "livelock". O código exemplificativo usa as informações armazenadas no TDB de forma exemplificativa; no entanto, aqueles versados na técnica serão capazes de usar a informação obtida a partir de, incluindo, porém sem limitações, locais na memória, registros de estado, códigos ou uma unidade de monitoramento de desempenho, unidade de tempo de execução de instrumentação e assim por diante. No código exemplificativo, a transação faz operações para evitar "livelock" quando ela corresponde a uma transação que ultrapassou (possivelmente) um limiar de travamento mútuo: SE (esta operação foi abortada) { ACESSAR informações em TDB SE (esta transação abortou outra transação) { travamento_mútuo ++ SE (travamento mútuo > limiar) evitar_livelock (); // tomar medidas para evitar livelock, // por exemplo, diminuir prioridade da transação atual; // esperar por um período de recuo; // sincronizar usando bloqueios; // e assim por diante } }

[0197] De acordo com o código exemplificativo, o código de reinicializar transação inclui verificações se a transação foi abortada em si e, por sua vez, outra transação foi abortada. Em uma concretização, um possível "livelock" é diagnosticado imediatamente. Em outra concretização, é executado um teste (não mostrado) se a transação atual e a transação que sofreu interferência fazem parte de um gráfico de interferência cíclica (isto é, cada transação, direta ou indiretamente, aborta a outra transação). Em uma concretização, quando mais do que um número limite de travamentos mútuos foram diagnosticados (travamento mútuo > limiar), medidas para evitar interferências são tomadas. Em uma concretização, quando mais do que um número limite de travamentos mútuos foi diagnosticado (travamento mútuo > limiar), medidas para evitar "livelock" são tomadas. Em uma concretização, as medidas para evitar interferências são invocadas pela chamada de uma função evitar_livelock (). Em algumas concretizações, estas medidas podem incluir, porém sem limitações, um ou mais de diminuir a prioridade da transação atual; esperar por um período de recuo; sincronizar usando bloqueios; e assim por diante.

[0198] Reiniciar otimização (seja de forma transparente em milicódigo ou em aplicativo): SE (esta operação foi abortada) { ACESSAR informação em TDB SE (esta operação abortou outra transação) {travamento_mútuo + +; SE ((travamento mútuo > limiar) && live_lock_loop_detectado ()) evitar_livelock (); // tomar medidas para evitar livelock, // por exemplo, diminuir prioridade da transação atual; // esperar por um período de recuo; // sincronizar usando bloqueios; // e assim por diante } }

[0199] De acordo com o código exemplificativo, o código de reiniciar transação inclui verificações se a transação foi abortada em si e, por sua vez, outra transação foi abortada. Em uma concretização, um possível "livelock" é diagnosticado imediatamente. Em uma concretização, quando mais do que um número limite de travamentos mútuos foram diagnosticados (travamento mútuo > limiar) , um teste live_lock_loop_detectado () é realizado, o qual pode acessar a informação adicional recebida através mensagens de estado de abortar em resposta e, opcionalmente, em conjunto com outros meios. Se a transação atual e a transação que sofreu a interferência são - ou, em outra concretização, podem ser - parte de um gráfico de interferência cíclica (isto é, cada transação, direta ou indiretamente aborta a outra transação), então, medidas para evitar "livelock" são tomadas. Em uma concretização, as medidas para evitar interferências são invocadas pela chamada de uma função evitar_livelock () . Em algumas concretizações, estas medidas podem incluir, porém sem limitações, um ou mais de diminuir a prioridade da transação atual; esperar por um período de recuo; sincronizar usando bloqueios; e assim por diante.

[0200] De acordo com uma concretização, a Figura 1 5 é um fluxograma 1500 que ilustra a forma como o processador (por exemplo, o processador solicitante CPU 1) responde à indicação de interferência, por exemplo, armazenada (e incrementada/rastreada) na tabela de armazenamento de rastreio de interferência de transação local 1350a a partir da informação no campo de estado de abortar transação 1010. O processador solicitante (CPU 1) reporta as estatísticas de interferência no bloco 1505. Os relatórios das estatísticas de interferência podem incluir gravação da informação de transação conforme discutido no bloco 1405. No bloco 1510, o processador solicitante (CPU 1) determina se sincronização adicional é possível para evitar a interferência repetida ao determinar quando o custo da interferência é muito alto. O custo da interferência é muito alto quando o processador solicitante (CPU 1) aborta repetidamente a (mesma) transação em execução sobre o processador receptor/remoto (CPU 2) um número predefinido de vezes (por exemplo, 4) e/ou a transação concluiu um número predefinido de ciclos de "clock" (por exemplo, 10.000 ciclos de "clock") de instruções antes de ser abortada.

[0201] Quando o processador solicitante (CPU 1) determina que a sincronização adicional não é possível para evitar a interferência repetida (transação repetida aborta no processador remoto (CPU 2), causada pela solicitação de dados a partir do processador solicitante (CPU 1) no bloco 1510, o processador solicitante (CPU 1) verifica se reotimização de código é possível no bloco 1515. Quando o processador solicitante (CPU 1) determina que reotimização é possível, o processador solicitante re-otimiza o código no bloco 1520. Quando o processador solicitante (CPU 1) determina que reotimização não é possível, o processador solicitante prossegue com código atual (incluindo medidas da tolerância, tal como recuo) no bloco 1525. Recuo é quando o processador solicitante determina esperar uma quantidade predefinida de tempo antes de fazer a solicitação de dados, de modo que o processador receptor/remoto (CPU 2) tenha tempo para que transação do processador receptor/remoto conclua a execução (sem ter de abortar).

[0202] Quando o processador solicitante (CPU 1) determina que sincronização adicional é possível para evitar a interferência repetida (transação repetida aborta com o processador remoto (CPU 2), causada pela solicitação de dados a partir do processador solicitante (CPU 1) no bloco 1510, o processador solicitante (CPU 1) usa sincronização alternativa no bloco 1530. O processador solicitante (CPU 1) verifica, por exemplo, o log na tabela de armazenamento de rastreio de interferência de transação local 1350 para determinar quando interferência repetida (da mesma transação (ou seja, que tem o mesmo endereço de cache/memória) ocorreu no processador receptor/remoto (CPU 2) no bloco 1535. Quando não há interferência repetida, o fluxo procede para o bloco 1525. Quando o processador solicitante (CPU 1) determina que não há interferência repetida (para a mesma operação abortada no processador receptor/remoto (CPU 2)), o processador solicitante verifica se reotimização de código é possível no bloco 1540. Quando reotimização é possível , o processador solicitante (CPU 1) re-otimiza o código no bloco 1545.

[0203] Quando o processador solicitante (CPU 1) determina que reotimização de código não é possível, o processador solicitante (CPU 1) é configurado para escolher permanentemente (e/ou por um período definido) o método de sincronização alternativa para esta transação particular (em execução no processador solicitante (CPU 1)) que solicita dados do processador receptor/remoto (CPU 2) no bloco 1550.

[0204] De acordo com uma concretização, a Figura 16 é um fluxograma 1600 que ilustra a forma como um processador (por exemplo, o processador solicitante CPU 1) responde à indicação de interferência, por exemplo, armazenada (e incrementada/rastreada) na tabela de armazenamento de rastreio de interferência de transação local 1350 a partir da informação no campo de estado de abortar transação 1010. A Figura 16 inclui os blocos da Figura 15, exceto o bloco 1605 que substitui o bloco 1540. Os blocos da Figura 15 não são repetidos.

[0205] Quando bloco 1535 é SIM, o fluxo prossegue para o bloco 1605 na Figura 16. No bloco 1605, o processador solicitante (CPU 1) verifica se reotimização ou sincronização alternativa é preferível. Quando a determinação no bloco 1605 é SIM, o fluxo prossegue para o bloco 1545. Quando a determinação no bloco 1605 é NÃO, o fluxo prossegue para o bloco 1550. No bloco 1540 da Figura 15, quando reotimização de código é possível, a reotimização código é sempre executada. Em 1605, uma métrica é calculada para determinar se o método de reotimização de código ou um método de sincronização alternativa (por exemplo, bloqueios) é desejado e um ou outro é selecionado. Isto pode ser com base, por exemplo , em um teste que compara o custo total do uso de um método de sincronização alternativa com o custo de uso de um método de reotimização para realizar a reotimização de modo a determinar qual deles é desejado. Outros métricas de custo são possíveis e consideradas pela presente descrição, tal como minimizar o custo de sobrecarga de reotimização, por exemplo, ao comparar o custo de reotimização com um limiar.

[0206] A Figura 17 é um fluxograma 1700 de um método (executado pelo processador 112a, 112b) para implementar um protocolo de coerência de acordo com uma concretização.

[0207] No bloco 1705, o processador solicitante 112a (CPU 1) envia uma solicitação (tais como solicitações 505, 605) por dados para o processador remoto 112b (CPU 2) através da interconexão 122. No bloco 1710, o processador solicitante 112a (CPU 1) recebe uma resposta (tais como as respostas 1005, 1105) a partir do processador remoto 112b, em que a resposta inclui o estado da transação (por exemplo, estado de abortar transação 1010) de uma transação remota (por exemplo, transação 320b) sobre o processador remoto 112b. No bloco 1715, o processador solicitante 112a acrescenta o estado da transação (informação a partir do campo 1010) da transação remota sobre o processador remoto em uma tabela de controle de interferência de transação local (por exemplo, tabela 1350a).

[0208] Além de um ou mais dos recursos descritos acima, ou como uma alternativa, outras concretizações podem incluir onde o estado de transação da transação remota é adicionado a um bloco de diagnóstico de transação (TBD) (pelo processador solicitante 112a). A operação remota é executada no processador remoto 112b e aborta a execução com base no envio da solicitação de dados ao processador remoto. A solicitação é ao solicitar uma transação (por exemplo, transação 320a) em execução no processador solicitante 112a que enviou a solicitação.

[0209] Além de um ou mais dos recursos descritos acima, ou como uma alternativa, outras concretizações podem incluir onde, com base na solicitação pela transação solicitante que faz com que a transação remota (por exemplo, transação 320b) seja abortada no processador remoto 112b, o processador solicitante 112a adiciona o estado de transação da transação remota (obtida a partir do campo 1010) à tabela de rastreio de interferência de transação local 1350a e incrementa uma contagem de transações abortadas que tenham ocorrido para a transação remota (cada transação 320b que é abortada em particular).

[0210] Além de um ou mais dos recursos descritos acima, ou como uma alternativa, outras concretizações podem incluir onde o estado de transação da transação remota recebida pelo processador solicitante 112a na resposta 1005, 1105 a partir do processador remoto 112b, indica que a transação remota (transação 320b) teve de ser abortada com base na recepção da solicitação 505, 605 a partir do processador solicitante 112a.

[0211] Além de um ou mais dos recursos descritos acima, ou como uma alternativa, outras concretizações podem incluir onde a tabela de armazenamento de rastreio de interferência de transação local 1350 mantém um número de transações que sofreram interferência e foram abortadas pela transação solicitante 320a em execução no processador solicitante 112a. A tabela de armazenamento de rastreio de interferência de transação local 1350 mantém informações que descrevem transações remotas 320b no processador remoto 112b (e outros processadores). As informações que descrevem as transações remotas 320b no processador remoto 112a incluem pelo menos um de: um tipo de interferência causada pela transação solicitante em execução no processador, uma identificação ou endereço de cada uma das transações remotas que foram abortadas pela transação solicitante, uma identificação de cada um dos processadores remotos nos quais ocorreu a interferência, um endereço de cada uma das transações remotas que foram abortadas e/ou uma medida de trabalho que tenha sido realizado por cada uma das transações remotas antes que elas fossem abortadas.

[0212] Os efeitos e benefícios técnicos incluem um protocolo de coerência estendido para incluir informações adicionais sobre o estado da transação. Quando um processador está em execução transacional, uma solicitação de coerência pode fazer com que a transação em execução no processador receptor seja abortada porque um conflito é detectado. A solicitação de protocolo de coerência é estendida com informações adicionais de que o processador receptor abortou sua transação em execução de acordo com concretizações.

[0213] A terminologia usada aqui é para fins de descrever apenas concretizações particulares e não se destina a ser limitativa da invenção. Conforme usado aqui, as formas no singular "um", "uma", "o" e "a" se destinam a incluir as formas no plural também, a menos que o contexto indique claramente o contrário. Será ainda entendido que os termos "compreende(m)" e/ou "compreendendo", quando usados no presente relatório descritivo, especificam a presença de aspectos, números inteiros, etapas, operações, elementos e/ou componentes estabelecidos, mas não excluem a presença ou adição de um ou mais de outros recursos, números inteiros, etapas, operações, componentes, elementos e/ou grupos dos mesmos.

[0214] As estruturas correspondentes, materiais, atos e equivalentes de todos os meios ou etapas mais a função de elementos nas reivindicações a seguir se destinam a incluir qualquer estrutura, material ou ato para executar a função em combinação com outros elementos reivindicados, conforme especificamente reivindicado. A descrição da presente invenção foi apresentada para fins de ilustração e descrição, mas não se destina a ser exaustiva ou limitar a invenção à forma descrita. Muitas modificações e variações serão evidentes para aqueles versados na técnica sem se afastar do escopo e espírito da invenção. A concretização foi escolhida e descrita de modo a explicar melhor os princípios da invenção e sua aplicação prática e para permitir que aqueles versados na técnica compreendam a invenção para várias concretizações com várias modificações, conforme adequado para o uso considerado em particular.

[0215] As descrições das várias concretizações da presente invenção foram apresentadas para fins de ilustração, mas não se pretende que sejam exaustivas ou limitadas às concretizações descritas. Muitas modificações e variações serão evidentes para aqueles versados na técnica sem se afastar do âmbito e do espírito das concretizações descritas. O terminologia usada aqui foi escolhida para explicar melhor os princípios das concretizações, a aplicação prática ou aprimoramento técnico em relação às tecnologias encontradas no mercado ou para permitir que aqueles versados na técnica compreendam as concretizações descritas aqui.

Claims (9)

1. Método implementado por computador para implementar um protocolo de coerência, o método caracterizado pelo fato de que compreende: enviar (1705), por um processador solicitante (112a), um pedido de dados para um processador remoto, sendo o referido pedido por uma transação solicitante executando no processador solicitante (112a) enviando o pedido; receber (1710), pelo processador solicitante, uma resposta do processador remoto, a resposta incluindo um status de transação de uma transação remota no processador remoto, em que o status de transação recebido na resposta do processador remoto inclui: um tipo de interferência no processador remoto causado pela transação solicitante em execução no processador solicitante, vários ciclos de trabalho do relógio tendo sido executados pela transação remota antes de serem interrompidos no processador remoto ou uma indicação de se uma reversão foi causada no processador remoto pelo envio da solicitação ao processador remoto; e adicionar (1715), pelo processador solicitante, o status da transação remota no processador remoto em uma tabela de rastreamento de interferência de transação (1350a); em que o processador solicitante é um processador separado do processador remoto.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o status da transação remota é adicionado a um bloco de diagnóstico de transação.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a transação remota é executada no processador remoto e aborta a execução com base no envio da solicitação de dados ao processador remoto.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação é efetuada por uma transação solicitante no processador solicitante que envia a solicitação.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que, com base na solicitação da transação solicitante que interrompe a transação remota no processador remoto, o processador solicitante adiciona o status da transação remota à tabela de rastreamento de interferência de transações e incrementa uma contagem de ocorrência de interrupção da transação para a transação remota.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o status da transação da transação remota, recebido pelo processador solicitante na resposta do processador remoto, indica que a transação remota teve que abortar com base no recebimento da solicitação do processador solicitante.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a tabela de rastreamento de interferência de transação local mantém um número de transações que foram interferidas e abortadas pela transação solicitante em execução no processador solicitante.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a tabela de rastreamento de interferência de transações mantém informações que descrevem transações remotas em processadores remotos; e em que as informações que descrevem as transações remotas nos processadores remotos incluem: uma identificação de cada um dos processadores remotos nos quais a interferência ocorreu; e um endereço de cada uma das transações remotas que foram abortadas.

9. Sistema de computador para implementar um protocolo de coerência, o sistema caracterizado pelo fato de que compreende: uma memória; e um processador, acoplado comunicativamente à referida memória, o sistema de computador configurado para executar um método conforme reivindicado em qualquer uma das reivindicações 1 a 8.

Images