Aula 7 · Sincronização · Prova 1

Objetivos da aula

O que você vai aprender

Identificar condições de corrida e a necessidade de exclusão mútua.

Explicar semáforos e monitores.

Aplicar wait/signal na proteção de regiões críticas.

Consolidar os conceitos para a Avaliação 1.

1 · Motivação

Quando a ordem estraga tudo

Vimos que threads e processos compartilham dados. Mas, quando dois acessam o mesmo dado ao mesmo tempo, o resultado pode ficar errado e imprevisível. Esse é o coração da concorrência — e o problema que a sincronização resolve.

Esta aula encerra o bloco 1 do curso e prepara a Avaliação 1. Dominar condições de corrida, exclusão mútua, semáforos e monitores é essencial para a prova e para tudo o que vem depois (deadlocks).

2 · Mapa

O que veremos nesta aula

Condição
de corrida→Exclusão
mútua→Semáforos→Monitores→Revisão
Prova 1

💡

Ideia central: garantir que apenas um processo/thread esteja na região crítica por vez — isso é exclusão mútua.

3 · Conceito

Condição de corrida e região crítica

Condição de corrida. Situação em que o resultado depende da ordem de execução de processos/threads que acessam dados compartilhados.
Região crítica. Trecho de código que acessa o recurso compartilhado e não pode ser executado por dois ao mesmo tempo.

4 · Conceito

Por que a corrida acontece

Operações que parecem atômicas (como saldo = saldo + 1) na verdade são várias instruções: ler, somar, gravar. Se duas threads intercalam essas etapas, uma atualização se perde.

A causa é a falta de atomicidade: a sequência ler-modificar-gravar pode ser interrompida no meio.

5 · Exemplo

O saldo bancário perdido

// duas threads executando saldo = saldo + 1 T1: ler saldo (100) T2: ler saldo (100) // corrida! T1: gravar 101 T2: gravar 101 // uma soma se perdeu

O esperado era 102, mas o resultado foi 101: uma atualização desapareceu por causa da intercalação.

6 · Interativo

Stepper: proteger com exclusão mútua

Passo 1

Antes de mexer no saldo, a thread pede permissão (entra na região crítica).

Passo 2

Só uma thread por vez recebe a permissão; as outras esperam.

Passo 3

A thread lê, soma e grava sem ser interrompida por outra na mesma região.

Passo 4

Ao terminar, libera a permissão; a próxima thread entra. Resultado correto: 102.

7 · Conceito

Exclusão mútua

Exclusão mútua. Garantia de que apenas um processo/thread esteja na região crítica por vez.

🔑

Exclusão mútua é a base da sincronização. Toda solução (semáforo, monitor, mutex) existe para garanti-la.

8 · Conceito

Semáforos

Semáforo. Variável inteira manipulada por duas operações atômicas: wait/P (decrementa; bloqueia se ficaria < 0) e signal/V (incrementa; libera quem espera).

Um semáforo binário (mutex) tem valor 0 ou 1 e protege uma região crítica. Um semáforo contador controla acesso a N recursos iguais.

9 · Analogia

A chave da sala

🚪 Analogia

O semáforo é uma chave que você deve lembrar de pegar (wait) e devolver (signal). Se esquecer de devolver, ninguém mais entra. O monitor é uma sala com porta automática que só deixa uma pessoa entrar por vez — menos chance de erro humano, pois a sala cuida do tranco.

10 · Comparação

Semáforo × monitor

	Semáforo	Monitor
Nível	Baixo (primitivo)	Alto (construção de linguagem)
Exclusão mútua	Pelo programador (wait/signal)	Garantida pela linguagem
Risco de erro	Maior (esquecer signal)	Menor
Exemplo	POSIX semaphores	synchronized (Java)

11 · Flow

O ciclo wait/signal

wait(s)
entra→Região
crítica→signal(s)
sai

wait(s); // entra na região crítica saldo = saldo + 1; signal(s); // sai da região crítica

12 · Aprofundamento

Monitores e variáveis de condição

Monitor. Construção de linguagem que encapsula dados e os procedimentos que os acessam, garantindo automaticamente exclusão mútua; usa variáveis de condição (wait/signal) para coordenar a espera por condições.

💡

Monitores são mais seguros que semáforos porque a exclusão mútua é garantida pela linguagem (ex.: synchronized em Java), não pelo programador. As variáveis de condição permitem dormir até que algo fique verdadeiro (ex.: buffer não vazio).

13 · Interativo

Verifique: valor inicial do mutex

Um semáforo binário usado como mutex é tipicamente inicializado em:

Inicia em 1: o primeiro wait entra (passa a 0); os demais esperam até um signal.

14 · Caso prático

Produtor-consumidor

Um problema clássico: um produtor coloca itens num buffer e um consumidor os retira. É preciso sincronizar para que o consumidor não leia de um buffer vazio nem o produtor escreva num buffer cheio.

Um semáforo conta posições cheias (o consumidor espera).
Outro conta posições vazias (o produtor espera).
Um mutex protege o acesso ao buffer.

15 · Erros comuns

Onde a sincronização falha

⚠️

Cuidado:
• Esquecer o signal deixa o recurso travado para sempre.
• Inverter a ordem dos waits em vários semáforos pode causar deadlock (Aula 8).
• Proteger só parte da região crítica não resolve a corrida.
• wait/signal precisam ser atômicos — por isso são providos pelo SO/linguagem.

16 · Dicas

Boas práticas de sincronização

✅

Dicas:
• Mantenha a região crítica curta: só o estritamente necessário.
• Sempre pareie wait com signal (entra/sai).
• Prefira construções de alto nível (monitores, locks) quando disponíveis.
• Para a prova: saiba calcular o resultado de uma corrida e proteger com semáforo.

17 · Interativo

Revele: por que monitor é mais seguro

Por que dizemos que o monitor é mais seguro que o semáforo?

Porque no semáforo a exclusão mútua depende do programador chamar wait antes e signal depois, na ordem certa — um esquecimento ou inversão causa bugs (recurso travado, deadlock, corrida). No monitor, a exclusão mútua é embutida na própria estrutura: ao entrar em um método sincronizado, o lock é adquirido automaticamente, e liberado ao sair. Isso remove a chance de erro humano de esquecer de liberar.

18 · Flashcards

Revisão relâmpago

Condição de corridavirar

Resultado depende da ordem de acesso a dados compartilhados.

Exclusão mútuavirar

Apenas um na região crítica por vez.

wait (P)virar

Decrementa o semáforo e bloqueia se necessário.

Monitorvirar

Estrutura de linguagem com exclusão mútua automática e variáveis de condição.

19 · Conexões

Revisão para a Prova 1

A Avaliação 1 cobre as semanas 1–6 mais esta. Conecte os temas:

Fundamentos (Aulas 1–2): SO, modos, chamadas.
Processos e threads (Aulas 3–4): estados, PCB, concorrência.
Escalonamento (Aula 5): FCFS, SJF, RR (saiba calcular).
IPC e sincronização (Aulas 6–7): comunicação e exclusão mútua.

A sincronização de hoje liga-se diretamente aos deadlocks (próxima aula): a ordem errada de wait pode travar tudo.

20 · Síntese

Fechando a aula

🔑

Em uma frase: condições de corrida surgem do acesso concorrente a dados compartilhados; a exclusão mútua garante um por vez na região crítica, os semáforos a implementam com wait/signal atômicos e os monitores oferecem a mesma garantia de forma mais segura, pela linguagem.

Mão na massa · colaborativo

Atividade em grupo · Mutirão de revisão (Prova 1)

Em grupos, montem um mapa de revisão das semanas 1–6 e resolvam a corrida.

⏱️ 30 min👥 grupos de 4🧩 estudo colaborativo

Roteiro

Cada integrante fica com um tema: introdução/estrutura, processos, threads, escalonamento.
Montem um mapa mental conectando os temas (uma página).
Resolvam o problema do saldo bancário usando um semáforo (escrevam o pseudocódigo com wait/signal).
Criem 2 questões originais por tema e troquem com outro grupo.

FundamentosSO, kernel, chamadas

Processos/threadsestados, PCB, concorrência

EscalonamentoFCFS, SJF, RR

Curadormonta o mapa final

📤 Entrega: Mapa mental de revisão + solução com semáforo + 8 questões autorais com gabarito.

Teste seu conhecimento

Mini-quiz · Aula 7

20 questões sobre esta aula. Escolha e veja a explicação na hora.

0/20

📌 Resumo — leve isto para a prova

Condições de corrida surgem do acesso concorrente a dados compartilhados sem atomicidade.
Exclusão mútua garante um processo por vez na região crítica.
Semáforos usam wait/signal atômicos; o mutex (binário) inicia em 1; o contador controla N recursos.
Monitores oferecem exclusão mútua de alto nível, garantida pela linguagem (ex.: synchronized).
A ordem errada de bloqueios leva a deadlocks — ponte para a Aula 8; reveja tudo para a Prova 1.