1 / 44

Controle de Concorrência em Sistemas Distribuídos

Controle de Concorrência em Sistemas Distribuídos. Aluno: Fabiano Costa Teixeira Disciplina: Sistemas Distribuídos Professor: Dr. Marcos José Santana. Roteiro. Introdução Transações Locks Controle Otimista de Concorrência Controle de Concorrência por Timestamps Conclusão. Introdução.

rusti
Download Presentation

Controle de Concorrência em Sistemas Distribuídos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

More Related