Capítulo 6: Sincronismo de processo
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
Silberschatz, Galvin e Gagne ©2007
Capítulo 6: Sincronismo de processo
Base
O problema da seção crítica
Solução de Peterson
Hardware de sincronismo
Semáforos
Problemas clássicos de sincronismo
Monitores
Exemplos de sincronismo
Transações indivisíveis
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.2
Silberschatz, Galvin e Gagne ©2007
Base
Acesso concorrente aos dados compartilhados
pode resultar em inconsistência de dados
Manutenção da consistência dos dados requer
mecanismos para garantir a execução ordenada
dos processos em cooperação
Suponha que queiramos oferecer uma solução para
um problema de consumidor-produtor que preencha
todos os buffers. Podemos fazer isso com um
contador inteiro que acompanha o número de
buffers cheios. Inicialmente, o contador é definido
como 0. Ele é incrementado pelo produtor depois de
produzir um novo buffer e é decrementado pelo
consumidor depois de consumir um buffer.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.3
Silberschatz, Galvin e Gagne ©2007
Produtor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.4
Silberschatz, Galvin e Gagne ©2007
Consumidor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.5
Silberschatz, Galvin e Gagne ©2007
Condição de race
count++ poderia ser implementado como
register1 = count
register1 = register1 + 1
count = register1
count-- poderia ser implementado como
register2 = count
register2 = register2 - 1
count = register2
Considere esta execução intercalando com “count = 5” inicialmente:
S0: produtor executa register1 = count {register1 = 5}
S1: produtor executa register1 = register1 + 1 {register1 = 6}
S2: consumidor executa register2 = count {register2 = 5}
S3: consumidor executa register2 = register2 - 1 {register2 = 4}
S4: produtor executa count = register1 {count = 6 }
S5: consumidor executa count = register2 {count = 4}
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.6
Silberschatz, Galvin e Gagne ©2007
Solução do problema de seção critica
1. Exclusão mútua – Se o processo Pi estiver executando em sua
seção crítica, então nenhum outro processo poderá estar
executando em suas seções críticas.
2. Progresso – Se nenhum processo estiver executando em sua
seção crítica e houver alguns processos que queiram entrar em
sua seção crítica, então a seleção dos processos que entrarão na
seção crítica em seguida não poderá ser adiada indefinidamente.
3. Espera limitada - É preciso haver um limite sobre o número de
vezes que outros processos têm permissão para entrar em suas
seções críticas depois que um processo tiver feito uma solicitação
para entrar em sua seção crítica e antes que essa solicitação seja
concedida
Suponha que cada processo seja executado em uma
velocidade diferente de zero
Nenhuma suposição referente à velocidade relativa dos N
processos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.7
Silberschatz, Galvin e Gagne ©2007
Problema de seção crítica
1.
2.
3.
4.
Condição race – Quando há acesso simultâneo aos
dados compartilhados e o resultado final depende da
ordem de execução.
Seção crítica – Seção do código onde os dados
compartilhados são acessados.
Seção de entrada - Código que solicita permissão para
entrar em sua seção crítica.
Seção de saída – Código executado após a saída da
seção crítica.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.8
Silberschatz, Galvin e Gagne ©2007
Estrutura de um processo típico
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.9
Silberschatz, Galvin e Gagne ©2007
Solução de Peterson
Solução em dois processos
Suponha que as instruções LOAD e STORE sejam
indivisíveis; ou seja, não podem ser interrompidas.
Os dois processos compartilham duas variáveis:
int turn;
Boolean flag[2]
A variável turn indica de quem é a vez de entrar na seção
crítica.
O array flag é usado para indicar se um processo está
pronto para entrar na seção crítica. flag[i] = true implica
que o processo Pi está pronto!
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.10
Silberschatz, Galvin e Gagne ©2007
Algoritmo para o processo Pi
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.11
Silberschatz, Galvin e Gagne ©2007
Seção crítica usando locks
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.12
Silberschatz, Galvin e Gagne ©2007
Hardware de sincronismo
Muitos sistemas oferecem suporte do hardware pra o
código da seção crítica
Uniprocessadores – poderiam desativar interrupções
Código atualmente em execução poderia ser
executado sem preempção
Geralmente muito ineficaz em sistemas
multiprocessadores
Sistemas operacionais usando isso não são
totalmente escaláveis
Máquinas modernas oferecem instruções de hardware
especiais indivisíveis
Indivisível = não interrompida
Ou testa word da memória e define valor
Ou troca conteúdo de duas words da memória
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.13
Silberschatz, Galvin e Gagne ©2007
Estrutura de dados para soluções de
hardware
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.14
Silberschatz, Galvin e Gagne ©2007
Solução usando GetAndSet
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.15
Silberschatz, Galvin e Gagne ©2007
Solução usando Swap
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.16
Silberschatz, Galvin e Gagne ©2007
Semáforo
Ferramenta de sincronismo que não exige espera ocupada
Semáforo S – variável inteira
Duas operações padrão modificam S: acquire() e release()
Originalmente chamadas P() e V()
Menos complicado
Só pode ser acessado por duas operações indivisíveis
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.17
Silberschatz, Galvin e Gagne ©2007
Semáforo como ferramenta geral de sincronismo
Semáforo de contagem – valor inteiro pode variar
por um domínio irrestrito
Semáforo binário – valor inteiro só pode variar
entre 0 e 1; pode ser mais simples de implementar
Também conhecidos como locks mutex
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.18
Silberschatz, Galvin e Gagne ©2007
Exemplo Java usando semáforos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.19
Silberschatz, Galvin e Gagne ©2007
Exemplo Java usando semáforos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.20
Silberschatz, Galvin e Gagne ©2007
Implementação de semáforo
Precisa garantir que dois processos não poderão
executar acquire () e release () no mesmo semáforo ao
mesmo tempo
Assim, a implementação se torna o problema de seção
crítica onde o código de espera e sinal são colocados na
seção crítica.
Agora poderia ter espera ocupada na implementação
da seção crítica
Mas o código de implementação é curto
Pouca espera ocupada se a seção crítica
raramente for ocupada
Observe que as aplicações podem gastar muito tempo
nas seções críticas e, portanto, essa não é uma boa
solução.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.21
Silberschatz, Galvin e Gagne ©2007
Implementação de semáforo sem espera ocupada
Com cada semáforo existe uma fila de espera
associada. Cada entrada em uma fila de espera
possui dois itens de dados:
valor (do tipo integer)
ponteiro para próximo registro na lista
Duas operações:
block – coloca o processo que chama a
operação na fila de espera apropriada.
wakeup – remove um dos processos na fila
de espera e o coloca na fila de prontos.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.22
Silberschatz, Galvin e Gagne ©2007
Implementação de semáforo sem espera ocupada (cont.)
Implementação de acquire():
Implementação de release():
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.23
Silberschatz, Galvin e Gagne ©2007
Deadlock e starvation
Deadlock – dois ou mais processos estão esperando
indefinidamente por um evento que só pode ser causado somente
por um dos processos esperando
Sejam S e Q dois semáforos inicializados com 1
P0
P1
S.acquire();
Q.acquire();
Q.acquire();
S.acquire();
.
.
.
.
.
.
S.release();
Q.release();
Q.release();
S.release();
Starvation – lock indefinido. Um processo pode nunca ser removido
da fila de semáforo em que ele é suspenso.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.24
Silberschatz, Galvin e Gagne ©2007
Problemas clássicos de sincronismo
Problema de buffer limitado
Problema de leitores-escritores
Problema do jantar dos filósofos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.25
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado
N buffers, cada um podendo manter um item
Mutex de semáforo inicializado com o valor 1
Semáforo cheio inicializado com o valor 0
Semáforo vazio inicializado com o valor N.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.26
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.27
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado
Método insert()
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.28
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado
Método remove()
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.29
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado (cont.)
A estrutura do processo produtor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.30
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado (cont.)
A estrutura do processo consumidor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.31
Silberschatz, Galvin e Gagne ©2007
Problema de buffer limitado (cont.)
A Factory
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.32
Silberschatz, Galvin e Gagne ©2007
Problema de leitores-escritores
Um conjunto de dados é compartilhado entre diversos
processos concorrentes
Leitores – só lêem o conjunto de dados; eles não
realizam quaisquer atualizações
Escritores – podem ler e escrever.
Problema – permite que vários leitores leiam ao mesmo
tempo. Apenas um único escritor pode acessar os dados
compartilhados de uma só vez.
Dados compartilhados
Conjunto de dados
Mutex de semáforo inicializado com 1.
db de semáforo inicializado com 1.
readerCount inteiro inicializado com 0.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.33
Silberschatz, Galvin e Gagne ©2007
Problema de leitores-escritores
Interface para locks de leitura-escrita
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.34
Silberschatz, Galvin e Gagne ©2007
Problema de leitores-escritores
Métodos chamados por escritores.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.35
Silberschatz, Galvin e Gagne ©2007
Problema de leitores-escritores
A estrutura de um processo escritor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.36
Silberschatz, Galvin e Gagne ©2007
Problema de leitores-escritores
A estrutura de um processo leitor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.37
Silberschatz, Galvin e Gagne ©2007
Problema do jantar dos filósofos
Dados compartilhados
Tigela de arroz (conjunto de dados)
Semáforo chopStick [5] inicializado com 1
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.38
Silberschatz, Galvin e Gagne ©2007
Problema do jantar dos filósofos (cont.)
A estrutura do Filósofo i:
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.39
Silberschatz, Galvin e Gagne ©2007
Problemas com semáforos
Uso correto das operações de semáforo:
mutex.acquire() …. mutex.release()
mutex.wait() … mutex.wait()
Omissão de mutex.wait () ou
mutex.release() (ou ambos)
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.40
Silberschatz, Galvin e Gagne ©2007
Monitores
Uma abstração de alto nível que oferece um
mecanismo conveniente e eficaz para o
sincronismo de processo
Somente um processo pode estar ativo dentro
do monitor em determinado momento
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.41
Silberschatz, Galvin e Gagne ©2007
Sintaxe de um monitor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.42
Silberschatz, Galvin e Gagne ©2007
Visão esquemática de um monitor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.43
Silberschatz, Galvin e Gagne ©2007
Variáveis de condição
Condição x, y;
Duas operações em uma variável de
condição:
x.wait () – um processo que invoca a
operação é suspenso.
x.signal () – retoma um dos processos
(se houver) que invocou x.wait ()
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.44
Silberschatz, Galvin e Gagne ©2007
Monitor com variáveis de condição
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.45
Silberschatz, Galvin e Gagne ©2007
Solução do jantar dos filósofos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.46
Silberschatz, Galvin e Gagne ©2007
Solução do jantar dos filósofos (cont.)
Cada filósofo I invoca as operações takeForks(i) e
returnForks(i) na seqüência a seguir:
dp.takeForks (i)
COMER
dp.returnForks (i)
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.47
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
Java oferece sincronismo em nível de linguagem.
Cada objeto Java possui um lock associado.
Esse lock é adquirido pela invocação de um método
sincronizado.
Esse lock é liberado na saída do método
sincronizado.
Os threads esperando para adquirir o lock do objeto
são colocados no conjunto de entrada para o lock
do objeto.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.48
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
Cada objeto possui um conjunto de entrada associado.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.49
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
Métodos sincronizados insert() e remove()
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.50
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java: wait/notify()
Quando um thread invoca wait():
1. O thread libera do lock do objeto;
2. O estado do thread é definido como Blocked;
3. O thread é colocado no conjunto de espera para
o objeto.
Quando um thread invoca notify():
1. Um thread qualquer T do conjunto de espera é
selecionado;
2. T é movido da espera para o conjunto de entrada;
3. O estado de T é definido como Runnable.
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.51
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
Entrada e conjuntos de espera
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.52
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java – buffer limitado
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.53
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java - buffer limitado
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.54
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
A chamada a notify() seleciona um thread
qualquer do conjunto de espera. É possível
que o thread selecionado não esteja de fato
esperando pela condição para a qual foi
notificado.
A chamada notifyAll() seleciona todos os
threads no conjunto de espera e os move para
o conjunto de entrada.
Em geral, notifyAll() é uma estratégia mais
conservadora do que notify().
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.55
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java – leitoresescritores
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.56
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java – leitoresescritores
Métodos chamados pelos leitores
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.57
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java – leitoresescritores
Métodos chamados pelos escritores
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.58
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
Ao invés de sincronizar um método inteiro, blocos
de código podem ser declarados como sincronizados
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.59
Silberschatz, Galvin e Gagne ©2007
Sincronismo em Java
Sincronismo de bloco usando wait()/notify()
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.60
Silberschatz, Galvin e Gagne ©2007
Recursos de concorrência em Java 5
Semáforos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.61
Silberschatz, Galvin e Gagne ©2007
Recursos de concorrência em Java 5
Uma variável de condição é criada primeiro pela criação de
ReentrantLock e chamada do seu método newCondition():
Quando isso é feito, é possível invocar os métodos
await() e signal().
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.62
Silberschatz, Galvin e Gagne ©2007
Exemplos de sincronismo
Solaris
Windows XP
Linux
Pthreads
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.63
Silberschatz, Galvin e Gagne ©2007
Sincronismo no Solaris
Implementa uma série de locks para dar suporte à
multitarefa, multithreading (incluindo threads em
tempo real) e multiprocessamento
Usa mutexes adaptativos por eficiência ao
proteger dados de segmentos de código curtos
Usa variáveis de condição e locks de leitoresescritores quando seções de código maiores
precisam de acesso aos dados
Usa turnstiles para ordenar a lista de threads
esperando para adquirir um mutex adaptativo ou
lock de leitor-escritor
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.64
Silberschatz, Galvin e Gagne ©2007
Sincronismo no Windows XP
Usa máscaras de interrupção para proteger o
acesso aos recursos globais em sistemas de
uniprocessador
Usa máscaras de interrupção para proteger o
acesso aos recursos globais em sistemas de
uniprocessador
Usa spinlocks em sistemas de multiprocessador
Também oferece objetos despachantes que
podem atuar como mutexes e semáforos
Objetos despachantes também podem fornecer
eventos
Um evento atua de modo semelhante a uma
variável de condição
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.65
Silberschatz, Galvin e Gagne ©2007
Sincronismo no Linux
Linux:
Desativa interrupções para implementar
seções críticas curtas
Linux oferece:
semáforos
spin locks
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.66
Silberschatz, Galvin e Gagne ©2007
Sincronismo Pthreads
API Pthreads é independente do OS
Ela oferece:
locks de mutex
variáveis de condição
Extensões não portáveis incluem:
locks de leitura-escrita
spin locks
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.67
Silberschatz, Galvin e Gagne ©2007
Transações indivisíveis
Modelo do sistema
Recuperação baseada em log
Pontos de verificação
Transações indivisíveis simultâneas
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.68
Silberschatz, Galvin e Gagne ©2007
Modelo do sistema
Garante que as operações acontecem como uma única
unidade lógica de trabalho, em sua inteireza, ou não
acontecem
Relacionado ao campo de sistemas de banco de dados
Desafio é assegurar a indivisibilidade apesar das falhas do
sistema de computação
Transação – coleção de instruções ou operações que realiza
única função lógica
Aqui, nos preocupamos com mudanças no
armazenamento estável – disco
A transação é uma série de operações read e write
Terminado com operação commit (transação bem
sucedida) ou abort (transação falhou)
Transação abortada deve ser rolled back para desfazer
quaisquer mudanças que ele realiza
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.69
Silberschatz, Galvin e Gagne ©2007
Tipos de meio de armazenamento
Armazenamento volátil – informação armazenada aqui não
sobrevive a falhas do sistema
Exemplo: memória principal, cache
Armazenamento não volátil – A informação normalmente
sobrevive a falhas
Exemplo: disco e fita
Armazenamento estável – Informação nunca se perde
Não é realmente possível, e por isso é aproximado pela
replicação ou RAID para dispositivos com modos de falha
independentes
Objetivo é garantir indivisibilidade da transação onde as falhas
causam perda de informações no armazenamento volátil
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.70
Silberschatz, Galvin e Gagne ©2007
Recuperação baseada em log
Registro de informações em armazenamento estável sobre
todas as modificações feitas por uma transação
Mais comum é o logging write-ahead
Log em armazenamento estável, cada registro de log
descreve operação de escrita de única transação,
incluindo
Nome da transação
Nome do item de dados
Valor antigo
Valor novo
<Ti inicia> escrito no log quando a transação Ti inicia
<Ti confirma> escrito quando Ti confirma
Entrada de log precisa alcançar o armazenamento estável
antes que a operação ocorra
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.71
Silberschatz, Galvin e Gagne ©2007
Algoritmo de recuperação baseado em
log
Usando o log, o sistema pode tratar de quaisquer erros de
memória volátil
Undo(Ti) restaura o valor de todos os dados atualizados
por Ti
Redo(Ti) define valores de todos os dados na transação Ti
para novos valores
Undo(Ti) e redo(Ti) devem ser idempotentes
Múltiplas execuções devem ter o mesmo resultado que
uma execução
Se o sistema falhar, restaura estado de todos os dados
atualizados em log
Se log contém <Ti starts> sem <Ti commits>, undo(Ti)
Se log contém <Ti starts> e <Ti commits>, redo(Ti)
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.72
Silberschatz, Galvin e Gagne ©2007
Pontos de verificação
Log poderia se tornar longo, e recuperação poderia levar
muito tempo
Pontos de verificação encurtam log e tempo de recuperação.
Esquema de ponto de verificação:
1. Enviar todos os registradores de log atualmente no
armazenamento volátil para o armazenamento estável
2. Enviar todos os dados modificados do armazenamento
volátil para o estável
3. Enviar um registro de log <checkpoint> para o log no
armazenamento estável
Agora a recuperação só inclui Ti, tal que Ti iniciou a execução
antes do ponto de verificação mais recente, e todas as
transações após Ti. Todas as outras transações já estão em
armazenamento estável
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.73
Silberschatz, Galvin e Gagne ©2007
Transações concorrentes
Devem ser equivalentes à execução serial serialização
Poderiam executar todas as transações na seção
crítica
Ineficiente, muito restritivo
Algoritmos de controle de concorrência oferecem
serialização
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.74
Silberschatz, Galvin e Gagne ©2007
serialização
Considere dois itens de dados A e B
Considere as transações T0 e T1
Execute T0, T1 de forma indivisível
Seqüência de execução chamada schedule
Ordem de transação executada de forma
indivisível chamada schedule serial
Para N transações, existem N! schedules
seriais válidos
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.75
Silberschatz, Galvin e Gagne ©2007
Schedule 1: T0 depois T1
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.76
Silberschatz, Galvin e Gagne ©2007
Schedule não serial
Schedule não serial permite execução sobreposta
Execução resultante não necessariamente incorreta
Considere schedule S, operações Oi, Oj
Conflito se acessar mesmo item de dados, com pelo
menos uma escrita
Se Oi, Oj consecutivos e operações de diferentes
transações & Oi e Oj não em conflito
Então S’ com ordem trocada Oj Oi equivalente a S
Se S puder se tornar S’ via swapping de operações não
em conflito
S é seriável em conflito
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.77
Silberschatz, Galvin e Gagne ©2007
Schedule 2: Schedule seriável simultâneo
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.78
Silberschatz, Galvin e Gagne ©2007
Protocolo de lock
Garante serialização pela associação de lock a cada item de
dados
Segue protocolo de lock para controle de acesso
locks
Compartilhado – Ti tem lock de modo compartilhado (S)
no item Q, Ti pode ler Q mas não escrever Q
Exclusivo – Ti tem lock em modo exclusivo (X) em Q, Ti
pode ler e escrever Q
Exige que cada transação no item Q adquira lock apropriado
Se lock já for mantido, nova solicitação pode ter que esperar
Semelhante ao algoritmo de leitores-escritores
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.79
Silberschatz, Galvin e Gagne ©2007
Protocolo de lock em duas fases
Geralmente, garante serialização em conflito
Cada transação emite solicitações de lock e
unlock em duas fases
Crescimento – obtendo locks
Encolhimento – liberando locks
Não impede deadlock
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.80
Silberschatz, Galvin e Gagne ©2007
Protocolos baseados em estampa de
tempo
Selecione a ordem entre transações com antecedência –
ordenação por estampa de tempo
Transação Ti associada à estampa de tempo TS(Ti) antes que Ti
inicie
TS(Ti) < TS(Tj) se Ti entrou no sistema antes de Tj
TS pode ser gerado pelo clock do sistema ou como
contador lógico incrementado em cada entrada de
transação
Estampas de tempo determinam a ordem de serialização
Se TS(Ti) < TS(Tj), sistema deve garantir schedule
produzido equivalente a schedule serial, onde Ti aparece
antes de Tj
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.81
Silberschatz, Galvin e Gagne ©2007
Implementação do protocolo baseado em
estampa de tempo
Item de dados Q recebe duas estampas de tempo
estampa-W(Q) – maior estampa de tempo de qualquer
transação que executou write(Q) com sucesso
estampa-R(Q) – maior estampa de tempo de read(Q) bem
sucedido
Atualizado sempre que read(Q) ou write(Q) é executado
Protocolo de ordenação por estampa de tempo garante que
qualquer read e write em conflito sejam executados na ordem
da estampa de tempo
Suponha que Ti execute read(Q)
Se TS(Ti) < estampa-W(Q), Ti precisa ler valor de Q que já
foi modificado
operação read rejeitada e Ti cancelada
Se TS(Ti) ≥ estampa-W(Q)
read executado, estampa-R(Q) definido como
max(estampa-R(Q), TS(Ti))
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.82
Silberschatz, Galvin e Gagne ©2007
Protocolo de ordenação de estampa de
tempo
Suponha que Ti execute write(Q)
If TS(Ti) < estampa-R(Q), valor Q produzido por Ti foi
necessário anteriormente e Ti assumiu que nunca seria
produzido
Operação write rejeitada, Ti cancelada
Se TS(Ti) < estampa-W(Q), Ti tentando escrever valor
obsoleto de Q
Operação write rejeitada e Ti cancelada
Caso contrário, write executado
Qualquer transação cancelada Ti recebe nova estampa de
tempo e é reiniciada
Algoritmo garante serialização por conflito e ausência de
deadlock
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.83
Silberschatz, Galvin e Gagne ©2007
Schedule possível sob protocolo de estampa
de tempo
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
6.84
Silberschatz, Galvin e Gagne ©2007
Final do Capítulo 6
Conceitos de Sistema Operacional com Java – 7a edição, 15/11/2006
Silberschatz, Galvin e Gagne ©2007
