controle de concorrência em sistemas distribuídos aluno: fabiano costa teixeira disciplina:...

Controle de Concorrência em Sistemas Distribuídos

Aluno: Fabiano Costa Teixeira

Disciplina: Sistemas Distribuídos

Professor: Dr. Marcos José Santana

2Controle de Concorrência em Sistemas Distribuídos

Roteiro

IntroduçãoTransaçõesLocksControle Otimista de ConcorrênciaControle de Concorrência por

TimestampsConclusão

3Controle de Concorrência em Sistemas Distribuídos

Introdução

Um servidor pode permitir acesso concorrenteProcessosThreads

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

4Controle de Concorrência em Sistemas Distribuídos

Transações

Foram originadas nos SGBD’sPodem ser utilizadas em servidores

transacionais de ArquivosPropriedades ACID:

AtomicidadeConsistência IsolamentoDurabilidade

5Controle de Concorrência em Sistemas Distribuídos

Transações

Uma maneira para garantir o isolamento é realizar as transações de forma serial

Essa solução é inaceitávelServidores compartilham recursos entre

diversos clientes Interatividade do sistema

Os servidores precisam maximizar a concorrência!!!!!

6Controle de Concorrência em Sistemas Distribuídos

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()x = b.getSaldo()b.setSaldo(x * 1,1);

b.setSaldo(x * 1,1);

x = 0 x = 0x = 200 x = 200

220

Perdido

240

7Controle de Concorrência em Sistemas Distribuídos

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 = 200100

b

saldo = 200300

a.retira(100);

total = a.getSaldo();total = total + b.getSaldo();

b.deposita(100);

total = 0total = 100total = 300total = 300

8Controle de Concorrência em Sistemas Distribuídos

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

9Controle de Concorrência em Sistemas Distribuídos

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 Read Não

Read Write Sim

Write Read Sim

10Controle de Concorrência em Sistemas Distribuídos

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 UU acessa j antes de T

11Controle de Concorrência em Sistemas Distribuídos

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

12Controle de Concorrência em Sistemas Distribuídos

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);

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)

13Controle de Concorrência em Sistemas Distribuídos

Locks: Two Phase Locking

Garante a equivalência serialDepois que a transação libera um lock

ela não pode adquirir mais nenhumA transação é dividida em duas fases:

Crescimento: Os locks são adquiridosEncolhimento: Os locks são liberados

O encolhimento ocorre após a execução de um commit ou rollback

14Controle de Concorrência em Sistemas Distribuídos

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

15Controle de Concorrência em Sistemas Distribuídos

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 LocksWrite Locks

16Controle de Concorrência em Sistemas Distribuídos

Locks: Compatibilidade de Operações

Lock existente

Lock solicitado

read write

none OK OK

read OK wait

write wait wait

17Controle de Concorrência em Sistemas Distribuídos

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

18Controle de Concorrência em Sistemas Distribuídos

Locks: Deadlocks

O uso de locks pode levar a uma situação de deadlock

Transação T Transação U

Operações Locks 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

19Controle de Concorrência em Sistemas Distribuídos

Locks: Deadlocks

É possível representar as “esperas” através de um grafo dirigido

Os vértices representam as transaçõesAs 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

espera por

20Controle de Concorrência em Sistemas Distribuídos

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 parteTimeout

21Controle de Concorrência em Sistemas Distribuídos

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 tentativasLeituras realizadas diretamente nos

objetos

22Controle de Concorrência em Sistemas Distribuídos

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:TrabalhoValidaçãoAtualização

23Controle de Concorrência em Sistemas Distribuídos

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

write

read

write

write

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

24Controle de Concorrência em Sistemas Distribuídos

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çãoBackward ValidationForward Validation

25Controle de Concorrência em Sistemas Distribuídos

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 Tv é compara-da com as transações T2

e T3.

Quais serão as transa-ções a serem compara-das?

26Controle de Concorrência em Sistemas Distribuídos

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

27Controle de Concorrência em Sistemas Distribuídos

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”

28Controle de Concorrência em Sistemas Distribuídos

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

29Controle de Concorrência em Sistemas Distribuídos

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

OBJ

OBJ Tentativa

Efetiva

30Controle de Concorrência em Sistemas Distribuídos

Controle por Timestamp

A versão efetiva do objeto possui um write timeStamp

Cada versão tentativa possui:write timestampConjunto de read Timestamp

31Controle de Concorrência em Sistemas Distribuídos

Controle por Timestamp

Operações write:Mantidas na versão tentativa até o commitExecutada no momento do closeTransactionCliente não precisa aguardar

Operações read:Direcionadas para a versão com maior

Timestamp que seja <= que a transaçãoPrecisa aguardar pelas transações

anteriores

32Controle de Concorrência em Sistemas Distribuídos

Controle por Timestamp

Não ocorre DeadlockRegra 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 Tcelse Aborta a transação Tc

33Controle de Concorrência em Sistemas Distribuídos

Controle por Timestamp: Exemplo de Escrita

OBJ T2 OBJ T3

Exemplo 1:

OBJ T1 OBJ T2

Exemplo 2:

OBJ T3

OBJ T1 OBJ T4

Exemplo 3:

OBJ T4OBJ T3

OBJ T4

Exemplo 4:

OBJ T3

OBJ T3

OBJ

OBJ Tentativa

Efetiva

34Controle de Concorrência em Sistemas Distribuídos

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

35Controle de Concorrência em Sistemas Distribuídos

Controle por Timestamp: Leitura

T2

Exemplo 1:

T2 T4

Exemplo 2:

T1

Exemplo 3:

T2

T4

Exemplo 4:

T3Seleciona

T3

Seleciona

T3Seleciona

Efetua leitura!

Efetua leitura!

Aguarda commit ou rollback!!

T3

OBJ

OBJ Tentativa

Efetiva

36Controle de Concorrência em Sistemas Distribuídos

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

37Controle de Concorrência em Sistemas Distribuídos

Multiversion Timestamp

Para um mesmo objeto é mantida uma lista das versões efetivas

Semelhante a um históricoOperações de read que chegam

“atrasadas” não precisam ser abortadasDa mesma forma que no sistema básico

de timestamps, as operações de escrita são realizadas em versões tentativas

38Controle de Concorrência em Sistemas Distribuídos

Multiversion Timestamp

Toda versão efetiva possui dois Timestamps:Da transação que a gravouMaior 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

39Controle de Concorrência em Sistemas Distribuídos

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

40Controle de Concorrência em Sistemas Distribuídos

T3

Multiversion Timestamp

r,w

r,w Tentativa

Efetiva

?,T1 ? ,T3 ?,T2

read

write

T3,T2

T5

read

T5 ,T3

T4

write

41Controle de Concorrência em Sistemas Distribuídos

Multiversion Timestamp

Maior uso de espaço em discoTransações read-only sempre são

realizadasRazoável nível de concorrênciaInexistência de Deadlocks

42Controle de Concorrência em Sistemas Distribuídos

Conclusão

Diversos mecanismos para o controle de concorrência

Diferença entre o grau de concorrênciaSerialização estática ou dinâmicaTransações somente leituraDeadlocksDecisão de qual transação abortar

43Controle de Concorrência em Sistemas Distribuídos

44Controle de Concorrência em Sistemas Distribuídos

Referência Bibliográfica

Coulouris, G., Dollimore, J., Kindberg, T.:

“Distributed Systems: Concepts and Design”

Addison-Wesley, páginas.: 465-510, 2001