Sincronização em SDs I

Bruno M. CarvalhoSala: 3B2

Horário: 35T34

Introdução

• Sincronização em SDs consiste na aplicação de técnicas que fazem com que os processos concordem com o tempo ou a ordem de ocorrência dos eventos do sistema

• Problemas em SDs sem sincronização. Ex.: make

• Vários algoritmos em SDs assumem que o sistema é sincronizado

• Geralmente necessita-se somente que os processos em máquinas diferentes concordem com a ordem dos eventos e não o tempo exato que os mesmos ocorreram

Sincronização de Clocks

• Quando cada máquina tem o seu próprio clock, um evento que aconteceu após outro pode ter um tempo associado menor

Clocks Lógicos

• Um clock geralmente um cristal de quartzo, oscila a uma frequência bem definida

• Frequências de cristais com mesma especificação diferem minimamente nas suas frequências (clock skew)

• Lamport – Em geral a sincronização não precisa ser absoluta

• Se dois processos não interagem, mesmo através de um terceiro processo, não é necessário que seus clocks sejam sincronizados

• Em geral, a concordância da ordem de ocorrência dos eventos é necessária

Algoritmo de Lamport

• Por esses motivos se usa o nome clocks lógicos, ao invés de clocks físicos, usados em sistemas onde se necessita do tempo correto de ocorrência de cada evento

• Lamport define a relação acontecimento-anterioridade (ab) que indica que todos os processos concordam que o evento a acontece primeiro e depois o b

– Se a e b são eventos no mesmo processo, e a acontece antes de b então a b é verdade

– Se a é o evento de uma mensagem sendo enviada por um processo e b é o evento de outro processo recebendo aquela mensagem então a b é verdade

Algoritmo de Lamport

• Se dois eventos acontecem em processos diferentes que não se comunicam, esses eventos são ditos concorrentes

• Mensagens são enviadas juntamente com clock da máquina do processo emissor

• Máquina que recebe mensagem ajusta seu prórpio clock caso seja necessário, isto é, quando seu clock tem um valor igual ou inferior ao da mensagem

• Pode-se usar número do processo para se resolver empates e implementar um clock global, isto é, cada evento tem um tempo associado e os tempos associados de todos os eventos são diferentes

Clocks Físicos

• Clocks lógicos podem não ser suficientes para alguns sistemas, como sistemas de tempo-real

– Como sincronizar os vários clocks do sistema com relógios do mundo real?

– Como sincronizá-los entre eles?

• Trânsito do sol – Quando o sol atinge o ponto mais alto no céu

• Dia solar – Intervalo entre dois trânsitos do sol consecutivos

• Segundo solar – (dia solar)/86400

• Rotação da terra não é constante!!

Clocks Físicos

• Computation of the mean solar day.

Clocks Físicos

• Há 300.000.000 de anos atrás, existiam 400 dias por ano, isto é, os dias estão ficando mais longos!

• Segundo solar médio – Média de um número de dias solares dividida por 86400

• Relógios atômicos medem tempo com uma precisão muito grande.

• Um segundo é definido como o tempo em que um átomo de Césio 133 faz 9.192.631.770 transições

• O Tempo Internacional Atômico (TAI) é uma média do tempo atômico medido por vários relógios atômicos no mundo

Clocks Físicos

• Segundos TAI tem duração constante ao contrário de segundos solares. Segundos extras são introduzidos quando necessário para que o TAI se manter em fase com o tempo solar

• Esse tempo corrigido é chamado de Tempo Coordenado Universal (UTC)

• Tempo UTC pode ser obtido através de telefone, rádio, satélite

Algoritmos de Sincronização de Clock

• O ideal seria que para todo t, Cp(t)=t, ou seja dC/dt=1

• A relação entre tempo do clock e UTC em função da variação da velocidade do clock do seu valor previsto

• Taxa de desvio máxima () é dada por

1 ÏdCdt

1 Ï

Algoritmo de Cristian

• Algoritmo centralizado adequado a sistemas com um único servidor de tempo

• Máquinas enviam mensagens em intervalos periódicos (< /

2 segundos) solicitando tempo correto ao servidor

• Estimação do tempo de envio-processamento e resposta

– Metade do tempo

– Média de várias requisições

– A mais rápida

Algoritmo de Berkeley

a) Um programa de gerenciamento de tempo solicita as outras máquinas seus valores de clock (servidor ativo)

b) As máquinas respondemc) O programa de gerenciamento de tempo informa as máquinas como devem

ajustar seus clocks

Algoritmos de Média

• Ambos métodos anteriores são centralizados• Pode-se dividir o tempo em intervalos de resincronização de

tamanho fixo. Ex. [T0+iR, T0+(i+1)R], onde T0 é um momento sicronizado anteriormente e R é um parâmetro do sistema

• No começo de cada intervalo, as máquinas emitem broadcast com seu tempo atual

• Pode-se fazer uma média geral, eliminar-se os m tempos maiores e menores e depois se fazer a média

• Pode-se ainda corrigir cada mensagem pela estimativa do tempo de propagação na rede

Múltiplas Fontes de Tempo Externas

• Usadas em sistemas que necessitem de uma precisão de sincronização muito alta

• Fontes de tempo externas podem ter precisão diferentes

• Tempos de propagação diferentes

• Se o sistema utiliza Ethernet, colisões vão aumentar a incerteza nos tempos propagados por broadcast

Uso de Clocks Sincronizados

• Serviços de mensagens com semântica no-máximo-uma

• Mensagens ordenadas numericamente armazenadas em um servidor, que assim diferencia entre novas mensagens e retransmisões. Problema – Na quebra do servidor a tabela de mensagens é perdida

• Com clocks sincronizados, mensagens carregam o número da conexão e um timestamp. O servidor checa a mensagem contra uma variável de tempo (G) e a aceita ou não

• G=TempoAtual – TempoMáximoVida – MáximoDesvioClock

• Após um reboot, servidor incrementa G e passa a rejeitar mensagens antigas

Consistência de Caches Usando Clocks

• Aluguéis de arquivos – Após um determinado tempo de uso, clientes tem de pedir renovação do aluguel, que só é dado caso ninguém mais esteja querendo usar o arquivo

• Elimina o problema de quebra de cliente

• Arquivos não alterados na hora da renovação do aluguel não precisam ser retransmitidos

• Clientes com arquivos abertos para leitura podem ser notificados da terminação prematura de aluguéis quando outro cliente acessar o arquivo para escrita

Exclusão Mútua

• Sistemas que usam múltiplos processos são mais facilmente implementados usando regiões críticas

• Quando um processo tem de usar certas estruturas de dados compartilhadas, ele entra em uma região crítica para garantir exclusão mútua, isto é, que nenhum outro processo usará estas estruturas de dados ao mesmo tempo

• Em sistemas uniprocessadores ou multiprocessadores com memória compartilhada, exclusão mútua pode ser conseguida usando-se semáforos ou monitores, que não são suficientes no caso de multicomputadores

Algoritmo Centralizado

• Processo coordenador recebe mensagens solicitando entrada em regiões críticas e permite ou não entradas de acordo com tabelas internas

• Processo solicita ao coordenadador entrada na região crítica e espera por permissão. Caso algum outro processo esteja usando a região crítica, o número do processo é posto em uma fila a espera da finalização da região crítica do outro processo

• Mensagens REQ-OK-REL • Coordenador também pode enviar mensagem negando

acesso no momento

Algoritmo Centralizado

• Processo solicitador pode estar bloqueado esperando pela permissão, senão terá que examinar mensagens que chegam após solicitação ou bloquear depois

• Garante exclusão mútua, evita inanição, simples e requer somente três mensagens

• Coordenador é um ponto único de falha, e pode se tornar um gargalo em sistemas grandes

Algoritmo Distribuído

• Requer ordenação total de eventos• Processo que quer entrar em uma região crítica monta

mensagem com seu número, timestamp e o nome da região crítica, e envia a todos os outros processos

• Processos que recebem uma mensagem deste tipo podem– Enviar mensagem OK para o processo solicitante

– Não enviar nada caso esteja na região crítica desejada (e enviar após sair da mesma)

– Comparar seu timestamp com o da mensagem e enviar OK caso seu timestamp tenha o maior valor dos dois, no caso de estar tentando entrar na mesma região crítica

Algoritmo Distribuído

• Após receber OKs de todos os outros processos, processo pode entrar na região crítica

• Exclusão mútua garantida sem deadlock ou inanição

• Número de mensagens necessárias é de 2(n-1)

• Ponto único de falha foi trocado por múltiplos pontos de falha!!!!

• Qualquer máquina pode se tornar um gargalo, já que todas se envolvem nas decisões de entrada em regiões críticas!

• Pode-se pedir permissão de uma fração dos processos somente (menos ineficiente)

• Estranho: Algoritmo distribuído é menos robusto que o centralizado

Algoritmo Token Ring

• Anel virtual é criado usando-se alguma ordenação, como por exemplo o número de endereço na rede

• Na inicialização do anel, o processo 0 recebe o token, e se deseja entrar em alguma região crítica, o faz (no máximo uma por vez) e envia o token para o próximo processo do anel após sair

• É simples de se ver que o algoritmo garante exclusão mútua e que inanição não ocorre

• Problema quando mensagem com o token se perde. Como detectar se um processo ainda está usando o token ou falhou?

Algoritmo Token Ring

• Quebra de processos pode ser detectada através de envio de mensagens ACK e temporizadores

• Algoritmo centralizado é menos sensível a quebra de processos que os distribuídos!!

Algoritmos de Eleição

• Vários algoritmos distribuídos utilizam um processo como coordenador, e algoritmos de eleição são utilizados para fazer esta escolha

• Processos tem um número único. Geralmente, algoritmos de eleição tentam localizar o processo com o maior número e o designam como coordenador

• Algoritmos também assumem que todos os processos sabem o número de todos os outros processos, mas que não sabem quais estão funcionando e quais não estão

• O objetivo é que ao final de sua execução, todos os processos concordem em quem é o novo coordenador

Algoritmo do Brigão(Bully)

• Um processo P, ao detectar a falha do coordenador, inicia a eleição do seguinte modo– P envia uma mensagem de eleição para todos os processor com

números maiores que o seu

– Se ninguém responde, P vence a eleição e se torna coordenador

– Se um dos processos responde, ele assume a eleição e P espera

• Qunado um processo vence a eleição, ele envia uma mensagem coordenador para todos os processos

• Se um processo que não estava funcionando volta a funcionar, ele inicia uma eleição e se tiver o maior número, assume a coordenação (daí o nome do algoritmo)

Algoritmo de Anel

• Assim que um processo P detecta a falha do coordenador, ele monta uma mensagem que contém seu número

• Caso o seu sucessor na rede não esteja funcionando, ele envia para o posterior. A cada vez que um processo recebe uma mensagem de eleição, ele adiciona seu número e passa a frente

• Após uma volta completa no anel a mensagem é recebida por P que examina seu conteúdo e envia uma mensagem para todos os processos do anel informando a identidade do novo coordenador

Transações Atômicas

• Abstração de mais alto-nível que permite que programadores abstraiam detalhes técnicos de como exclusão mútua é obtida, como deadlocks são prevenidos, etc.

• Implementam a semântica de ou-tudo-ou-nada em sua execução, isto é, se a transação é cancelada antes de sua finalização, os objetos e arquivos do sistema alterados por esta transação atômica voltam ao estado anterior ao início da mesma

• Implementação é complicada pelo fato que transação pode estar sendo executada em várias máquinas simultaneamente

O Modelo Transacional

• O modelo transacional garante exclusão mútua e suporta operações atômicas

• Considere uma transação composta das seguintes operações:– Retirada de R$100 da conta 1– Depósito de R$100 na conta 2

• A interrupção da transação após a execução da operação 1 e antes da execução da operação 2 faz com que o dinheiro desapareça

• Armazenamento estável – Projetado para suportar quebras de computadores, é implementado usando-se discos backup (exemplo: RAID)

Primitivas de Transações

Escreve dados em um arquivo, tabela, etc. WRITE

Lê dados de um arquivo, tabela, etc. READ

Aborta a transação e restaura valores antigosABORT_TRANSACTION

Finaliza a transação e tenta aprová-laEND_TRANSACTION

Marca o início de uma transaçãoBEGIN_TRANSACTION

DescriçãoPrimitiva

Exemplo: Reserva de Vôos

a) Transação para a reserva dos três vôos é aceita

b) Transação para a reserva dos três vôos é abortada quando o terceiro vôo está cheio

BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi full =>ABORT_TRANSACTION (b)

BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi;END_TRANSACTION

(a)

Propriedades de Transações [ACID]

1) Atomicidade: Transações são indivisíveis para o resto do sistema

2) Consistência: Invariantes do sistema não são violadas

3) Isolamento: Transações concorrentes não interferem com as outras (serialização)

4) Durabilidade: Quando uma transação é aceita, as mudanças são permanentes (requer um mecanismo de aceitação distribuído)

Serialização

BEGIN_TRANSACTION x = 0; x = x + 3;END_TRANSACTION

(c)

BEGIN_TRANSACTION x = 0; x = x + 2;END_TRANSACTION

(b)

BEGIN_TRANSACTION x = 0; x = x + 1;END_TRANSACTION

(a)

Ilegalx = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3;Schedule 3

Legalx = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3;Schedule 2

Legalx = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3Schedule 1

Permite execução paralela, mas o resultado final tem de ser igual a uma ordem sequencial de execução das transações

Classificação de Transações

• Transações Planas (Flat) – Limitadas – Resultados parciais não podem ser aceitos– Exemplo: Manter primeiros dois trechos do vôo do

exemplo anterior

• Transações aninhadas– Transações iniciam subtransações, que por sua vez podem

iniciar sub-subtransações

• Transações distribuídas– Transações planas mas distribuídas em relação ao acesso

aos dados

• Transações aninhadas permitem uma organização hierárquica do sua transação mas complicam as operações de aborto e aceitação

• Transações distribuídas são planas mas usam dados distribuídos (exemplo: bancos de dados do JFK e do aeroporto de Nairobi)

Transações Aninhadas X Transações Distribuídas

Áreas de Trabalho Privadas

• Nesta técnica para implementação de transações atômicas, os arquivos e outros objetos que serão utilizados pela transação são copiados para uma área de trabalho local

• Área pública só é atualizada após aceitação da transação, e no caso de aborto da transação, sua área privada é removida

• O problema desta técnica é o custo computacional de se copiar os arquivos e objetos para todas as transações quando em geral poucas são abortadas

• Opções são a cópia somente dos arquivos e objetos a serem modificados, ou ainda somente as partes de objetos ou arquivos que são modificadas

Áreas de Trabalho Privadas

a) Descritor de arquivos original e blocos de disco

b) Cópia do descritor soment. Cópia de blocos somente quando escritos

• Exemplo: Bloco 0 modificado e bloco 3 adicionado. Blocos novos são chamados de shadow blocks

c) Substituição do arquivo original (novos blocos mais descritor) após aceitação

Writeahead Log

b) – d) Log grava valores antigos e novos antes de cada operação ser executada

• Se transação é aceita não é necessário se fazer nada

• Se a transação é abortada, usa-se o log para fazer um rollback (restauração dos valores antigos)

Log

[x = 0 / 1]

[y = 0/2]

[x = 1/4]

(d)

Log

[x = 0 / 1]

[y = 0/2]

(c)

Log

[x = 0 / 1]

(b)

x = 0;

y = 0;

BEGIN_TRANSACTION;

x = x + 1;

y = y + 2

x = y * y;

END_TRANSACTION;

(a)

Protocolo de Aceitação de Duas Fases

• Execução do protocolo é iniciada pelo coordenador após a última operação da transação ter sido iniciada

• Coordenador (geralmenteo processo que iniciou a transação) escreve uma entrada no log informando que vai iniciar o protocolo de aceitação e envia mensagens para todos os processos envolvidos (subordinados) na execução da transação informando-os que se preparem para a aceitação

• Subordinado checa se está pronto para aceitação, escreve em um log local, e envia a resposta para o coordenador

• Coordenador decide pela aceitação ou não e envia mensagem informando sua decisão

Controle de Concorrência

• Necessário para que transações não interfiram com as execuções de outras transações

• Método mais simples é o controle de concorrência otimista, onde cada transação pode fazer o que quiser, e caso ocorra algum problema, o sistema tenta solucioná-lo

• Mantém tabelas contendo informações sobre arquivos e objetos alterados pelas transações. Na fase de aceitação, caso uma transação não tenha conflitos, é aceita

• Funciona melhor com áreas de trabalho privadas• Como não usa locks, não existem deadlocks

Locking em Duas Fases

• Granularidade menor dos locks permite maior paralelismo mas usa mais recursos e aumenta a probabilidade da ocorrência de deadlocks

• Locking em duas fases faz com que transação tenha que obter todos os locks antes de atualizar arquivos destes locks. Dividido em fase de crescimento e diminuição

• A não obtenção de algum lock acarreta na liberação de todos os outros locks. Se todas as transações usam locking em duas fases, elas são serializáveis

Locking em Duas Fases

Locking Estrito em Duas Fases

• A fase de encolhimento só começa após aceitação ou aborto da transação

• Outras transações só acessam valores escritos por transações aceitas

• Elimina a necessidade de abortos em cascata, onde transações que acessaram arquivos que foram alterados por transações que posteriormente não foram aceitas, são abortados também

• Diminui paralelismo• Ordenação de locks pode ser usada para impedir a criação

de deadlocks

Locking Estrito em Duas Fases

Deadlocks

• Quatro estratégias para se lidar com deadlocks são:

– Ignorar

– Detecção: Permitir que deadlocks ocorram, detectá-los e tentar se recuperar do problema

– Prevenção: Estaticamente fazer com que deadlocks sejam estruturamente impossíveis de acontecer

– Evitar: Evitar a ocorrência de dealocks através de uma alocação de recursos cuidadosa (não é utilizada, já que algoritmos precisam saber antes de executar quais recursos precisam)

Detecção de Deadlocks Centralizada

• Máquinas locais mantém grafos de recursos para seus processos e uma máquina coordenadora mantém um grafo global do sistema

• Ao detectar um ciclo, coordenador mata um dos processos

• Atualizações podem ser feitas uma a uma, em blocos (em intervalos de tempo regulares) ou ser solicitadas explicitamente pelo coordenador

• Mensagens perdidas ou desordenadas podem levar a detecção de falsos deadlocks, acarretando na eliminação desnecessária de processos.

Detecção de Deadlocks Centralizada

• Uso do algoritmo de Lamport para eliminar problema de desordenação e até de mensagens perdidas

• Coordenador, ao detectar um deadlock, pode perguntar aos processos envolvidos no deadlock se algum lock foi liberado antes do tempo marcado no lock que fechou um ciclo no grafo de recursos

Detecção de Deadlocks Distribuída

• Em um algoritmo desta classe (Chandy-Misra-Haas) processos que suspeitam que um deadlock está acontecendo enviam mensagens “sondas” para investigar

• Mensagens incluem o número do processo que iniciou a sondagem, o número do processo que a está reenviado agora, e o número do processo para o qual está se enviando a mensagem

• Deadlock é detectado caso sondagem retorna ao processo que a iniciou, que pode, então, cometer suicídio. Caso mais de um processo detecte o deadlock, todos eles se suicidariam (desnecessariamente)

• Solução – solicitar que o processo com maior número identificador se suicide

Prevenção de Deadlocks Distribuída

• Uma abordagem é a de se ordenar recursos globalmente e exigir que processos os adquiram em ordem

• Em sistemas com tempo global e transações atômicas dois outros algoritmos são possíveis

• Cada transação tem um tempo global associado, que indica seu início

• No primeiro algoritmo, se um processo mais antigo quer um recurso de um processo mais novo, ele espera, e no caso de um processo mais novo querer um recurso de um processo mais antigo ele é terminado (wait-die)

Prevenção de Deadlocks Distribuída

• No segundo algoritmo, se um processo mais antigo quer um recurso de um processo mais novo, ele preempta (toma o recurso), e no caso de um processo mais novo querer um recurso de um processo mais antigo ele espera (wound-wait)