A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Controle de Concorrência em Sistemas Distribuídos Aluno: Fabiano Costa Teixeira Disciplina: Sistemas Distribuídos Professor: Dr. Marcos José Santana."— 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 Controle de Concorrência em Sistemas Distribuídos 2 Roteiro Introdução Transações Locks Controle Otimista de Concorrência Controle de Concorrência por Timestamps Conclusão

3 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 4 Transações Foram originadas nos SGBDs Podem ser utilizadas em servidores transacionais de Arquivos Propriedades ACID: Atomicidade Consistência Isolamento Durabilidade

5 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 6 Transações: Lost Update Transação T x = b.getSaldo(); b.setSaldo(x * 1,1); Transação U x = b.getSaldo(); b.setSaldo(x * 1,1); b saldo = 200 x = b.getSaldo() b.setSaldo(x * 1,1); x = 0 x = Perdido 240

7 Controle de Concorrência em Sistemas Distribuídos 7 Transações: Retrievals Problem Transação V a.retira(100); b.deposita(100); Transação W total = a.getSaldo(); total = total + b.getSaldo(); a saldo = b saldo = a.retira(100); total = a.getSaldo(); total = total + b.getSaldo(); b.deposita(100); total = 0total = 100total = 300

8 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 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 ReadWriteSim WriteReadSim

10 Controle de Concorrência em Sistemas Distribuídos 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 TTransaçã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 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 12 Locks Simplesmente bloquear um objeto e liberá-lo logo após o uso não garante a equivalência serial Transação TTransação U x = b.read(); (lock b) y = b.read(); (wait b) b.write(x-10); y = b.read(); (lock b) y = y + c.read(); (lock c) c.write(x+10); x = c.read(); (lock c) unlock(b) unlock(c) unlock (b) unlock (c)

13 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 16 Locks: Compatibilidade de Operações Lock existente Lock solicitado readwrite noneOK readOKwait writewait

17 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 18 Locks: Deadlocks O uso de locks pode levar a uma situação de deadlock Transação TTransação U OperaçõesLocksOperaçõesLocks a.deposito(100); b.saque(100); write lock a Aguarda U b.deposito(100); a.saque(100); write lock b Aguarda T

19 Controle de Concorrência em Sistemas Distribuídos 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 T x por uma transação T y Um circuito encontrado no grafo indica a existência de um DeadLock TU espera por

20 Controle de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 TvTv TiTi Regra write read write read write T i não pode ler objetos escritos por T v T v não pode ler objetos escritos por T i T i não pode escrever objetos escritos por T v e T v não pode escrever objetos escritos por T i

24 Controle de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 Transação T v é compara- da com as transações T 2 e T 3. Quais serão as transa- ções a serem compara- das?

26 Controle de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 29 Controle por Timestamp As versões tentativas devem ser efetivadas na ordem dos timestamps das transações T1T1 T2T2 T3T3 T4T4 OBJ Tentativa Efetiva

30 Controle de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 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 de Concorrência em Sistemas Distribuídos 32 Controle por Timestamp Não ocorre Deadlock Regra para a escrita d um objeto D por uma transação T c : 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 de Concorrência em Sistemas Distribuídos 33 Controle por Timestamp: Exemplo de Escrita OBJ T 2 OBJ T 3 Exemplo 1: OBJ T 1 OBJ T 2 Exemplo 2: OBJ T 3 OBJ T 1 OBJ T 4 Exemplo 3: OBJ T 4 OBJ T 3 OBJ T 4 Exemplo 4: OBJ T 3 OBJ Tentativa Efetiva

34 Controle de Concorrência em Sistemas Distribuídos 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 D selected = D com maior write timestamp <= T c if (D selected é uma versão efetiva) Executa read sobre a versão D selected else Aguarda até que a transação que gerou D selected seja efetivada ou abortada e reaplica a regra de leitura }else Aborta a transação Tc

35 Controle de Concorrência em Sistemas Distribuídos 35 Controle por Timestamp: Leitura T2T2 Exemplo 1: T2T2 T4T4 Exemplo 2: T1T1 Exemplo 3: T2T2 T4T4 Exemplo 4: T3T3 Seleciona T3T3 T3T3 Efetua leitura! Aguarda commit ou rollback!! T3T3 OBJ Tentativa Efetiva

36 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 39 Multiversion Timestamp Operações de escrita de transações diferentes não são conflitantes Regra de escrita: if (read timestamp of D maxEarlier <= T c { executa o write na versão tentativa com w-ts T c }else Aborta a transação Tc

40 Controle de Concorrência em Sistemas Distribuídos 40 T3T3 Multiversion Timestamp r,w Tentativa Efetiva ?,T1 ?,T1 ?,T 3 ?,T2 ?,T2 read write T 3, T 2 T5T5 read T 5,T 3 T4T4 write

41 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 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 Controle de Concorrência em Sistemas Distribuídos 43

44 Controle de Concorrência em Sistemas Distribuídos 44 Referência Bibliográfica Coulouris, G., Dollimore, J., Kindberg, T.: Distributed Systems: Concepts and Design Addison-Wesley, páginas.: , 2001


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

Apresentações semelhantes


Anúncios Google