Controle de Concorrência em Sistemas Distribuídos

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. Perdido Transações: Lost Update b saldo = 200 220 240 x = b.getSaldo() x = 0 x = 200 x = 0 x = 200 x = b.getSaldo() b.setSaldo(x * 1,1); b.setSaldo(x * 1,1);

7. Transações: Retrievals Problem a b saldo = 200 100 saldo = 300 200 a.retira(100); total = 300 total = 0 total = 100 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

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” 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 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

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

19. espera por T U espera por 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 Txpor uma transação Ty • Um circuito encontrado no grafo indica a existência de um DeadLock

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

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. OBJ Tentativa OBJ Efetiva 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

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. OBJ Tentativa OBJ Efetiva Controle por Timestamp: Exemplo de Escrita Exemplo 1: 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

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. Seleciona Seleciona OBJ Tentativa OBJ Efetiva Controle por Timestamp: Leitura Exemplo 1: T3 T2 Seleciona Efetua leitura! Exemplo 2: T2 T4 T3 Efetua leitura! Exemplo 3: T3 T1 T2 Aguarda commit ou rollback!! Exemplo 4: 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. T3 T5 T4 r,w Tentativa r,w Efetiva Multiversion Timestamp read read write write ?,T1 T3,T2 ?,T2 T5 ,T3 ? ,T3

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

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