Sistemas Distribuídos Coordenação

Sistemas Distribuídos Coordenação Vinícius Fernandes Soares Mota 1

Até agora Vimos algumas formas ara rocessos sincronizarem suas ações Estudamos vários roblemas que odem surgir com a concorrência de rocessos 2

Agora 3 Nosso objetivo é verificar como os mecanismos de sincronização centralizada odem ser estendidos a um ambiente distribuído. Existe um curso somente sobre algoritmos distribuídos. Nosso objetivo é introduzir alguns dos rinciais asectos.

4 Sincronização de Processos Processos Cooerativos: Afetam ou são afetados or outros rocessos. Podem comartilhar um mesmo esaço de endereços lógicos, ou um mesmo arquivo. Endereços lógicos: threads, ou rocessos leves. Acesso concorrente a dados ode gerar inconsistência de dados. Devem ser desenvolvidos mecanismos ara garantir a consistência de dados comartilhados or rocessos cooerativos.

5 Jantar dos filósofos... Formulado or Dijkstra, 1965 Cada filósofo come Usando 2 garfos simultaneamente Usa ou larga 2 garfos Modela a disuta or recursos

6 Jantar dos filósofos... Algoritmo básico Pense até que o garfo esquerdo esteja disonível; Quando estiver, egá-lo; Pense até que o garfo direito esteja disonível; Quando estiver, egá-lo; Quando ossuir ambos os garfos, comer or um eríodo fixo de temo; Então, coloque o garfo direito ara baixo; Então, coloque o garfo esquerdo ara baixo; Reetir desde o início.

7 O caso rodutor/consumidor O caso rodutor/consumidor: Suonha rocessos com memória comartilhada Memória consiste em um buffer de tamanho variável que abriga itens em estoque. Variável counter indica o número de itens em estoque (itens no buffer. Toda vez que um roduto é adicionado incrementa-se o counter. Toda vez que um roduto é retirado decrementa-se o counter.

8 O caso rodutor/consumidor / inicializacao fim = 0; ini = 0; n = 0; // codigo do rodutor for (i=0; i<1000; i++) { while (n == caacidade); buf[fim] = roduzir(i); fim = (fim + 1) % caacidade; n++; } // codigo do consumidor for (i=0; i<1000; i++) { while (n == 0) ; consumir(buf[ini]); ini = (ini + 1) % caacidade; n--; }

9 O caso rodutor/consumidor Algoritmos corretos isoladamente. Podem causar inconsistência se rodados em aralelo. Problema: Sessão Crítica!!! Região de código onde um rocesso está acessando dados comartilhados. Problemas de inconsistência ocorrem em sessões críticas e devem ser evitados.

10 O roblema da sessão crítica Soluções ara o roblema da sessão crítica devem satisfazer os requisitos: Exclusão mútua: Se um rocesso está executando uma sessão crítica (acessando dados comartilhados) os demais rocessos devem eserar. Progressão:Se não há rocessos executando em sessão crítica, somente rocessos que não estão executando no final da sessão odem cometir ela sessão crítica. Esera limitada:existe um limite no número de vezes que outros rocessos são ermitidos a entrar na sessão crítica aós m rocesso requisitar a sessão crítica.

11 Sessão Crítica Algoritmo básico enter() // entra na seção crítica bloqueia, se necessário resourceaccesses() // acessa recursos comartilhados na seção crítica exit() // sai da seção crítica outros rocessos odem entrar agora

Sistemas centralizados: Semáforos 12 Um semáforo é um tio abstrato de dados que ossui um valor inteiro, uma lista de rocessos em esera e duas oerações P (do holandês Proberen, testar) V (do holandês Verhogen, incrementar) A imlementação do semáforo deve ser atômica Garantido or linguagens que oferecem o recurso

Sistemas centralizados: Semáforos 13 Para garantir exclusão mútua a uma determinada região (região crítica), cada rocesso deve chamar a oeração P antes de acessar tal região e chamar a oeração V aós sair dessa região Oeração P sobre um semáforo S Testa se o rocesso que executou P(S) ode ou não entrar na região crítica Oeração V sobre um semáforo S Sinaliza ao semáforo que o rocesso não está mais na região crítica e retira outro rocesso da fila de esera

Sistemas centralizados: Semáforos 14 // S.valor começa com 1 P(S) S.valor -= 1; Se (S.valor < 0) // bloqueia o rocesso e insere em S.fila V(S) S.valor += 1; Se (S.valor <= 0) // retira algum rocesso de S.fila e o coloca em execução

O caso rodutor/consumidor com semáforos 15 // inicializacao fim = 0; ini = 0; n = 0; semaforo S; S.valor = 1; // codigo do rodutor for (i=0; i<1000; i++) { while (n == caacidade) ; buf[fim] = roduzir(i); fim = (fim + 1) % caacidade; P(S); n++; V(S); } // codigo do consumidor for (i=0; i<1000; i++) { while (n == 0) ; consumir(buf[ini]); ini = (ini + 1) % caacidade; P(S); n--; V(S); }

O caso rodutor/consumidor com semáforos 16 Código do rodutor:... roduzir um item... wait(emty); wait(mutex);... Adicionar um item no vetor... signal(mutex); signal(full);

O caso rodutor/consumidor com semáforos 17 Código do consumidor: wait(full); wait(mutex);... remove nextc do buffer;... signal(mutex); signal(emty);... consome o róximo item...

Sincronização em Sistemas Distribuídos Conceitos imortantes no rojeto de qualquer alicação distribuída: Comunicação Sincronização Sincronização em alicações distribuídas: Como garantir exclusão mútua no acesso a seções críticas? Como garantir atomicidade na execução de uma transação distribuída? Como alocar recursos evitando a ocorrência de deadlocks? 18

Sincronização em Sistemas Distribuídos 19 Sincronização em sistemas centralizados: utiliza memória comartilhada Exemlos: semáforos, monitores etc Sincronização em sistemas distribuídos: utiliza troca de mensagens Imlementada via algoritmos distribuídos Mesmo determinar se um evento A ocorreu antes ou deois de um evento B é mais comlexo do que em um sistema centralizado

20 Exclusão Mútua Distribuída Sistemas Centralizados: memória comartilhada (semáforos, monitores etc) Sistemas Distribuídos: via troca de mensagens Requisitos: Segurança: No máximo um rocesso ode estar executando na seção crítica (SC) Subsistência: Um rocesso que requisita acesso à SC, obtém este acesso em algum momento. Ou seja, não há deadlock ou starvation. Ordenação: Se uma requisição ara entrar na SC aconteceu antes de outra, a entrada de SC é garantida na ordem

Primeira Solução: Algoritmo Centralizado 21 Existe um rocesso coordenado (PC) Gerencia o acesso à SC Processos comuns Antes de entrar na SC: enviam request ao PC Quando recebem rely: entram na SC Quando saem da SC: enviam release ao PC Processo Coordenador: Enfileira request quando a SC ocuada Desenfileira request ao receber um release

Primeira Solução: Algoritmo Centralizado 22 Queue of requests Server 4 2 3. Grant token 1 1. Request token 2. Release token 4 2 3

Primeira Solução: Algoritmo Centralizado (cont.) 23 Número de mensagens trocadas ara entrar na SC: duas (um request e um rely) Saída da SC: uma mensagem (release). Problema: rocesso que centraliza todas as informações e decisões Solução: distribuir a fila de edidos Todos os nós recebem todos os edidos Pedidos são ordenados elos nós da mesma maneira

Algoritmos de Exclusão Mútua Distribuída 24 Princiais Algoritmos: Token Ring (*) Ricart e Agrawala (*) Osvaldo e Roucariol Maekawa (*) Algoritmos que serão estudados a seguir

25 Algoritmo Token Ring Suõe que os rocessos são organizados como um anel lógico, or onde circula uma token Não exige que a toologia da rede seja em anel (anel lógico e não físico) Cada rocesso deve armazenar a configuração comleta do anel Correção: ao rocesso de osse da token é garantido o acesso à SC

26 Algoritmo Token Ring Idéia básica: Se um rocesso não deseja entrar na SC: Ao receber a token, reassa a mesma ara seu vizinho Se um rocesso deseja entrar na SC: Aguarda a assagem da token e a retém Número de mensagens trocadas: entre 1 e n-1

27 Algoritmo Token Ring 1 2 n 3 4 Token

28 Algoritmo Token Ring Vantagens: simlicidade Desvantagem: tratamento de erros Perda da mensagem que contém a token Deve-se gerar a token novamente Quando gerar? Quem deve gerar? Travamento de rocessos Deve-se reconfigurar o anel

29 Algoritmo de Ricart e Agrawala Algoritmo executado or cada rocesso Pi, que comartilha uma SC ( i <= n): Variáveis: estado: estado da seção crítica OSN: relógio lógico do rocesso HSN: maior valor do timestam de qualquer mensagem enviada ou recebida Inicialização: estado:= livre; HSN:= 0;

30 Algoritmo de Ricart e Agrawala 1. Broadcast de mensagem request com timestam 2. 2. Aós receber um request, envia ack SE -Não quer entrar na SC, ou -Está tentando entrar na SC, mas seu timestam é maior do que o enviado (Se está na SC, coloque o request no buffer) 3. Entrar na SC, quando receber ack de todos 4. Aós sair da SC, envia ack ara cada request endent e antes de fazer nova requisição

31 Algoritmo de Ricart e Agrawala On initialization state := RELEASED; To enter the section state := WANTED; Multicast request to all rocesses; request rocessing deferred here T := request s timestam; Wait until (number of relies received = (N 1)); state := HELD; On receit of a request <T i, i > at j (i j) if (state = HELD or (state = WANTED and (T, j ) < (T i, i ))) then queue request from i without relying; else rely immediately to i ; end if To exit the critical section state := RELEASED; rely to any queued requests;

32 Algoritmo de Ricart e Agrawala Número de mensagens trocadas ara entrar na SC: 2 (n -1) n-1: requests n-1: relys Vantagem: Distribuído (sem um onto central de falha) Desvantagem: Em qual situação este algoritmo ode ser ineficiente?

33 Algoritmo de Ricart e Agrawala Número de mensagens trocadas ara entrar na SC: 2 (n -1) n-1: requests n-1: relys Vantagem: Distribuído (sem um onto central de falha) Desvantagem: Em qual situação este algoritmo ode ser ineficiente? Caso de Mútlilas requisições or um SC

34 Jantar dos filósofos... Uma solução distribuída (Kandy, 1984) Para cada ar de filósofos que disutam um recurso, crie um garfo e dêo ao filósofo com a ID mais baixa (n ara o agente Pn). Cada garfo ode estar sujo ou limo. Inicialmente, todos os garfos estão sujos. Quando um filósofo quer usar um conjunto de recursos (isto é, comer), esse filósofo deve obter os garfos de seus vizinhos. Para cada garfo o filósofo não tem, ele envia uma mensagem de edido. Quando um filósofo com um garfo recebe uma mensagem de edido, ele mantem o garfo se ele está limo, mas desiste quando está sujo. Se o filósofo envia o garfo, ele lima o garfo antes de fazê-lo. Deois que um filósofo acaba de comer, todos os garfos ficam sujos. Se outro filósofo havia edido anteriormente um dos garfos, o filósofo que acabou de comer lima o garfo e o envia.

35 Reforçando 1) No algoritmo do servidor central ara exclusão mútua, descreva uma situação na qual duas requisições não são rocessadas na ordem acontece-antes 2) Qual o imacto na largura de banda de algoritmos de exclusão mútua 3) O algoritmo de Ricart e Agrawala tem o roblema de que se um rocesso cai e não resonde a uma solicitação de outro rocesso ara acessar recursos, a falta de resosta será interretada como negação de ermissão. Solução: todas as solicitações serem resondidas imediatamente ara facilitar a detecção de rocessos quebrados. Existem circunstâncias em que mesmo este método é insuficiente? Discutir.

36 Reforçando 1) No algoritmo do servidor central ara exclusão mútua, descreva uma situação na qual duas requisições não são rocessadas na ordem acontece-antes O Processo A envia uma solicitação ra ara entrar na Seção crítica e envia uma mensagem m ara B. Ao receber m, B envia um edido rb ara entrar na SC. Para satisfazer a regra aconteceu-antes ra deve ser concedido antes de rb. No entanto, devido a atrasos de roagação de mensagem, rb chega ao servidor antes de ra, Eles serão atendidos na ordem oosta.

37 Reforçando 2) Qual o imacto na largura de banda de algoritmos de exclusão mútua A largura de banda será dividida elo temo que cada rocesso segurar a exclusão mútua

38 Reforçando 3) O algoritmo de Ricart e Agrawala tem o roblema de que se um rocesso cai e não resonde a uma solicitação de outro rocesso ara acessar recursos, a falta de resosta será interretada como negação de ermissão. Suonha que um rocesso nega ermissão e, em seguida, falha. O rocesso solicitante ensa que ele está vivo, mas a ermissão nunca virá. Uma saída é o solicitante não bloquear realmente, mas sim ir dormir or um eríodo de temo fixo, aós o qual ele examina todos os rocessos que negaram ermissão ara ver se eles ainda estão em execução.

42 Algoritmos de Eleição Gruo de rocessos deve eleger um coordenador. Alicações: Gerenciamento de rélicas, Algoritmos centralizados de coordenação, sincronização, etc... A escolha do coordenador deve ser única, mesmo que vários rocessos de eleição tenham começado simultaneamente.

43 Requisitos Algoritmos de Eleição Segurança Um rocesso conhece o rocesso eleito Subsistência Todos os rocessos articiam da eleição

Algoritmo de eleição baseado em anel 44 Processos organizados em toologia anel Todos rocessos iniciam como não articiantes Marca a si mesmo como articiante e envia uma mensagem com seu id no sentido horário Ao receber Se o id recebido é maior, encaminha ara o vizinho Se o id é menor Se é não articiante, substitui elo seu id Se é articiante, não encaminha a mensagem

Algoritmo de eleição baseado em 45 anel 3 17 4 24 9 1 15 28 24 Nota: Eleição iniciada elo rocesso 17. O maior identificador encontrado até então é o 24. Processos com estado articiante estão escurecidos

Algoritmo Tirano (Valentão) The bully algorithm 46 Membros do gruo devem conhecer a identidade e o endereço dos outros membros. Mensagens: Eleição: enviada ara anunciar o início de uma nova eleição Resosta: enviada em resosta a uma mensagem de eleição. Coordenador: enviada ara anunciar o coordenador. Um rocesso inicia uma eleição quando notar uma falha no coordenador (não recebeu uma resosta a uma requisição deois de um certo número de tentativas ou aós um certo timeout, or exemlo).

Algoritmo Tirano The bully algorithm 47 Processo inicia eleição enviando mensagem de eleição ara os rocessos de maior rioridade. Estágio 1 1 eleição resosta eleição 2 resosta 3 eleição C 4

Algoritmo Tirano The bully algorithm 48 Processo inicia eleição enviando mensagem de eleição ara os rocessos de maior rioridade. Processos resondem a mensagem e iniciam nova eleição Estágio 1 Estágio 2 1 1 eleição resosta eleição 2 resosta 2 eleição resosta 3 eleição 3 eleição C 4 C 4

Algoritmo Tirano The bully algorithm 49 Processo inicia eleição enviando mensagem de eleição ara os rocessos de maior rioridade. Processos resondem a mensagem e iniciam nova eleição Processo coordenador envia mensagem de coordenador. Estágio 1 Estágio 2 Estágio 3 1 1 timeout 1 eleição resosta eleição 2 resosta 2 2 eleição resosta 3 eleição 3 3 eleição C 4 C 4 4

Algoritmo Tirano The bully algorithm 50 Processo inicia eleição enviando mensagem de eleição ara os rocessos de maior rioridade. Processos resondem a mensagem e iniciam nova eleição Processo coordenador envia mensagem de coordenador. Se nenhuma mensagem for recebida, rocesso se declara coordenador e envia mensagem de coordenador ara os rocessos de menor rioridade. Estágio 1 Estágio 2 Estágio 3 Eventualmente... Estágio 4 1 1 timeout 1 1 eleição resosta coordenador eleição 2 resosta 2 2 C 2 eleição resosta 3 eleição 3 3 3 eleição C 4 C 4 4 4

51 Reforçando 1) Comare o algoritmo de eleição do anel com o algoritmo valentão 2) Esboce um seudo-código ara ambos os algoritmos.

Consenso 52 Um dos roblemas mais fundamentais de SDs Informalmente: como fazer um gruo de rocessos concordar em um valor Qual é a hora Fazer ou não fazer commit Quem é arte do gruo Quem é o líder do gruo Podemos seguir ara o róximo asso do algoritmo Já vimos algumas instâncias, agora vejamos o mais geral

Um ouco de formalismo 53 Consenso: Para chegar a um consenso, todo rocesso i começa no estado indeciso e roõe um único valor v i, extraído de um conjunto D (i = 1, 2,..., N). Os rocessos se comunicam, trocando valores. Cada rocesso configura o valor de uma variável de decisão d i. Ao fazer isso, ele entra no estado decidido, no qual não ode mais mudar d i (i = 1, 2,..., N).

Um ouco de formalismo 54 Conjunto de nós Falhas or fail-sto ou bizantinas Mais tarde: fail-sto + recueração Objetivo: todos os rocessos i õem o mesmo valor em uma variável d i Não queremos amarrar de onde vem v i v i ode ser roosto or um nó ou decidido a artir de várias roostas

Um ouco de formalismo 55 P 1 d 1 :=roceed d 2 :=roceed P 2 v 1 =roceed 1 v 2 =roceed Consensus alg ori thm v 3 =abort P 3 (crashes)

Um ouco de formalismo 56 Requisitos: 1. Concordância: Todos os nós escolhem o mesmo valor ara d i 2. Validade: O valor escolhido deve ter sido roosto or algum nó 3. Terminação: Alguma hora, todos decidem um valor Pode ser descrito de formas ligeiramente diferentes: generais bizantinos, consistência interativa, atomic broadcast,...

57 Consenso Consistência interativa Consenso com líder (generais bizantinos)

Uma boa nova 58 Esses roblemas são equivalentes Resolvemos um, resolvemos todos Por exemlo: CI a artir de GB: GB várias vezes, cada rocesso é líder uma vez C de CI: roda CI, deois nós alicam mesma função a vetor ara decidir Por aí vai...

Uma éssima nova 59 Nenhum desses consensos ode ser garantido em um sistema assíncrono com falha Não odemos decidir não levar em conta a oinião de um nó; ele ode estar aenas lento e mandar a mensagem na hora errada Consenso ode acontecer frequentemente ou ode acontecer raramente Não funciona com crash não funciona com falhas bizantinas

Mas a vida continua 60 Se consenso não funciona em um sistema assíncrono e: Multicast totalmente ordenado? Relicação consistente? Commits em gruo? Na rática, vivemos com isso: Tentamos até que o sistema se comorte como síncrono Mascaramos falhas: eseramos até o rocesso resonder Usamos detectores de falha: Crash fail-sto (semre que funciona, claro)

Comentário 61 Eleição é um consenso Casos de falha, não há acordo sobre quem é líder Qualquer um ode achar que é Se gente demais achar que é, há um livelock Como um líder não bagunça trabalho do outro? Proostas são ordenadas Todos os nós sabem qual a mais recente que conhecem

70 Questões Sincronização Vinícius Fernandes Soares Mota