Controle de Concorrência em Sistemas Distribuídos

Apresentação em tema: "Controle de Concorrência em Sistemas Distribuídos"— Transcrição da apresentação:

1 Controle de Concorrência em Sistemas Distribuídos
Aluno: Fabiano Costa Teixeira Disciplina: Sistemas Distribuídos Professor: Dr. Marcos José Santana

2 Roteiro Introdução Transações Locks Controle Otimista de Concorrência
Controle de Concorrência por Timestamps Conclusão

3 Introdução Um servidor pode permitir acesso concorrente
Processos Threads Se o projeto não for bem feito, as ações dos clientes podem interferir umas nas outras Essas interferências podem resultar em resultados incorretos dos objetos

4 Transações Foram originadas nos SGBD’s
Podem ser utilizadas em servidores transacionais de Arquivos Propriedades ACID: Atomicidade Consistência Isolamento Durabilidade

5 Transações Uma maneira para garantir o isolamento é realizar as transações de forma serial Essa solução é inaceitável Servidores compartilham recursos entre diversos clientes Interatividade do sistema Os servidores precisam maximizar a concorrência!!!!!

6 Transações: Lost Update
b saldo = 200 220 240 Transação T x = b.getSaldo(); b.setSaldo(x * 1,1); Transação U x = b.getSaldo() x = 200 x = 0 x = 200 x = 0 x = b.getSaldo() Perdido b.setSaldo(x * 1,1); b.setSaldo(x * 1,1);

7 Transações: Retrievals Problem
saldo = 200 100 saldo = 300 200 Transação V a.retira(100); b.deposita(100); Transação W total = a.getSaldo(); total = total + b.getSaldo(); a.retira(100); total = 0 total = 100 total = 300 total = 300 total = a.getSaldo(); total = total + b.getSaldo(); b.deposita(100);

8 Transações: Equivalência Serial
Quando as transações são executadas serialmente não há problemas Se transações concorrentes tiverem suas operações intercaladas de forma que o resultado final seja o mesmo que alguma das combinações seriais, essa intercalação é SERIALMENTE EQUIVALENTE! Protocolos de controle de concorrência se baseiam nesse princípio

9 Transações: Equivalência Serial
Um mesmo objeto pode ser requisitado por operações de transações diferentes É dito que um par de operações é conflitante quando o resultado depende da ordem que elas aparecem na execução Operações de transações diferentes Conflito? Read Não Write Sim

10 Transações: Equivalência Serial
É possível definir a ordem das operações conflitantes “Para que duas transações possuam equivalência serial, é necessário e suficiente que todos os pares de operações conflitantes sejam executados na mesma ordem” Transação T Transação U x = read(i); write(i, 10); write(j, 20); y = read(j); write(j, 30); z = read(i); Não há equivalência serial: T acessa i antes de U U acessa j antes de T

11 Locks Um mecanismo que faz com que duas transações concorrentes sejam serialmente equivalentes Quando ocorre um conflito de operações, o objeto acessado é “bloqueado” Outro cliente deve aguardar até que o objeto seja “liberado” para poder acessá-lo

12 Locks Simplesmente bloquear um objeto e liberá-lo logo após o uso não garante a equivalência serial Transação T Transação U x = b.read(); (lock b) y = b.read(); (wait b) b.write(x-10); unlock(b) y = b.read(); (lock b) unlock (b) y = y + c.read(); (lock c) unlock (c) x = c.read(); (lock c) c.write(x+10); unlock(c)

13 Locks: Two Phase Locking
Garante a equivalência serial Depois que a transação libera um lock ela não pode adquirir mais nenhum A transação é dividida em duas fases: Crescimento: Os locks são adquiridos Encolhimento: Os locks são liberados O encolhimento ocorre após a execução de um commit ou rollback

14 Locks: Compatibilidade de Operações
Se duas transações acessam o mesmo objeto somente para leitura não há riscos de inconsistência Um mecanismo simples que observa uma operação read da mesma maneira que uma operação write reduz a concorrência mais que o necessário

15 Locks: Compatibilidade de Operações
É interessante que seja possível ter diversas transações lendo um objeto ou somente uma alterando-o Mecanismo referenciado como “many reades / single writer” São utilizados dois tipos de locks: Read Locks Write Locks

16 Locks: Compatibilidade de Operações
Lock existente Lock solicitado read write none OK wait

17 Locks: Promoção Uma mesma transação pode efetuar operações de leitura e escrita em um mesmo objeto Quando realizada uma leitura, um read lock é atribuído ao objeto Se for solicitada uma leitura é feita uma promoção para write lock Um write lock não pode virar um read lock

18 Locks: Deadlocks O uso de locks pode levar a uma situação de deadlock
Transação T Transação U Operações Locks a.deposito(100); b.saque(100); write lock a Aguarda U b.deposito(100); a.saque(100); write lock b Aguarda T

19 Locks: Deadlocks É possível representar as “esperas” através de um grafo dirigido Os vértices representam as transações As arestas representam a espera de uma transação Tx por uma transação Ty Um circuito encontrado no grafo indica a existência de um DeadLock T U espera por

20 Locks: Deadlocks Uma vez que um Deadlock é detectado, para resolvê-lo é preciso abortar uma das transações envolvidas É necessário decidir qa respeito de qual transação abortar: Número de ciclos dos quais ela faz parte Timeout

21 Controle Otimista de Concorrência
Parte do princípio de que a possibilidade de haver duas transações em conflito é baixa A transação prossegue sem solicitar locks Escritas realizadas em cópias tentativas Leituras realizadas diretamente nos objetos

22 Controle Otimista de Concorrência
Quando é solicitado o encerramento da transação é verificado se há conflitos Se houver conflito uma transação é abortada e deve ser reiniciada Cada transação possui três fases: Trabalho Validação Atualização

23 Controle Otimista: Validação de Transações
São mantidos os grupos de objetos lidos e objetos alterados por uma transação Na validação é verificada a existência de conflitos entre as operações das transações concorrentes Tv Ti Regra write read 1 2 3 Ti não pode ler objetos escritos por Tv Tv não pode ler objetos escritos por Ti Ti não pode escrever objetos escritos por Tv e Tv não pode escrever objetos escritos por Ti

24 Controle Otimista: Validação de Transações
Cada transação que entra na fase de validação recebe, sequencialmente, um número identificador Duas formas de validação Backward Validation Forward Validation

25 Controle Otimista: Backward Validation
A transação validada é comparada com aquelas que foram iniciadas antes do começo de sua fase de validação e que já foram efetivadas Quais serão as transa- ções a serem compara- das? Transação Tv é compara- da com as transações T2 e T3.

26 Controle Otimista: Backward Validation
É necessário realizar a validação apenas da regra 2 Se a regra não for obedecida é necessário abortar a transação sob validação É necessário manter o conjunto de objetos escritos de uma transação até que todas aquelas que possuem sobreposição a ela sejam validadas

27 Controle Otimista: Forward Validation
A transação validada é comparada com aquelas em atividade É necessário realizar a validação apenas da regra 1 Transações read-only sempre passam pela validação Transações em conflito estão ativas, flexibilizando a escolha de “qual abortar”

28 Controle por Timestamp
Toda transação, no momento de sua criação, recebe um timestamp O timestamp define a posição da transação Cada transação que aplica uma operação de write possui uma versão “tentativa” do objeto

29 Controle por Timestamp
As versões tentativas devem ser efetivadas na ordem dos timestamps das transações T1 T2 T3 T4 OBJ OBJ OBJ OBJ OBJ Tentativa Efetiva OBJ

30 Controle por Timestamp
A versão efetiva do objeto possui um write timeStamp Cada versão tentativa possui: write timestamp Conjunto de read Timestamp

31 Controle por Timestamp
Operações write: Mantidas na versão tentativa até o commit Executada no momento do closeTransaction Cliente não precisa aguardar Operações read: Direcionadas para a versão com maior Timestamp que seja <= que a transação Precisa aguardar pelas transações anteriores

32 Controle por Timestamp
Não ocorre Deadlock Regra para a escrita d um objeto D por uma transação Tc: if (Tc >= Maior read timestamp de D && Tc > write timestamp da versão efetiva Executa o write na versão tentativa Tc else Aborta a transação Tc

33 Controle por Timestamp: Exemplo de Escrita
OBJ T2 OBJ T3 Exemplo 2: OBJ T1 OBJ T2 OBJ T3 Exemplo 3: OBJ T1 OBJ T4 OBJ T3 OBJ T4 OBJ T3 Exemplo 4: OBJ T4 OBJ T3 OBJ Tentativa Efetiva

34 Controle por Timestamp: Leitura
A leitura de um objeto deve ser realizada seguindo os Timestamps. Sendo a regra: if (Tc >= Maior write timestamp da versão efetiva de D){ let Dselected = D com maior write timestamp <= Tc if (Dselected é uma versão efetiva) Executa read sobre a versão Dselected else Aguarda até que a transação que gerou Dselected seja efetivada ou abortada e reaplica a regra de leitura }else Aborta a transação Tc

35 Controle por Timestamp: Leitura
Exemplo 1: T3 T2 Seleciona Efetua leitura! Exemplo 2: Seleciona T2 T4 T3 Efetua leitura! Exemplo 3: T3 T1 T2 Seleciona Aguarda commit ou rollback!! Exemplo 4: OBJ Tentativa Efetiva T4 T3

36 Controle por TimeStamps
O commit deve ser feito na ordem dos timestamps Se for necessário aguardar por transações anteriores o cliente não precisa aguardar Necessidade de armazenar as cópias tentativas pertencentes a transações efetivas em meios persistentes

37 Multiversion Timestamp
Para um mesmo objeto é mantida uma lista das versões efetivas Semelhante a um histórico Operações de read que chegam “atrasadas” não precisam ser abortadas Da mesma forma que no sistema básico de timestamps, as operações de escrita são realizadas em versões tentativas

38 Multiversion Timestamp
Toda versão efetiva possui dois Timestamps: Da transação que a gravou Maior Timestamp de leitura Operações de leitura são sempre aceitas, mas podem precisar aguardar Cuidado com as transações de escrita que afetariam uma leitura já realizada

39 Multiversion Timestamp
Operações de escrita de transações diferentes não são conflitantes Regra de escrita: if (read timestamp of DmaxEarlier <= Tc{ executa o write na versão tentativa com w-ts Tc }else Aborta a transação Tc

40 Multiversion Timestamp
read read write write ?,T1 ?,T2 T3,T2 ? ,T3 T5 ,T3 r,w Tentativa Efetiva

41 Multiversion Timestamp
Maior uso de espaço em disco Transações read-only sempre são realizadas Razoável nível de concorrência Inexistência de Deadlocks

42 Conclusão Diversos mecanismos para o controle de concorrência
Diferença entre o grau de concorrência Serialização estática ou dinâmica Transações somente leitura Deadlocks Decisão de qual transação abortar

43

44 Referência Bibliográfica
Coulouris, G., Dollimore, J., Kindberg, T.: “Distributed Systems: Concepts and Design” Addison-Wesley, páginas.: , 2001