Baixe Guia Completo: Processos, Threads e Gerenciamento de Memória e outras Exercícios em PDF para Sistemas Operacionais, somente na Docsity!
GUIA COMPLETO: PROCESSOS, THREADS E
GERENCIAMENTO DE MEMÓRIA
Material de Estudo Uni cado com Exemplos Didáticos
PARTE I: FUNDAMENTOS DE PROCESSOS E THREADS
CAPÍTULO 1: CONCEITOS FUNDAMENTAIS
1.1 O Que é um Processo?
Antes de entender threads e gerenciamento de memória, você precisa saber o que é um processo.
Um processo é:
Uma instância de um programa em execução Possui seu próprio espaço de memória independente Tem seus próprios registradores, variáveis e recursos É como se fosse um "mundo isolado"
Exemplo visual:
PROCESSO = Programa em execução isolado
Processo Google Chrome: ├─ Memória própria: 500 MB ├─ Registradores próprios ├─ Arquivos abertos: cookies, cache └─ Completamente separado de outros processos
1.2 O Que é uma Thread?
Uma thread é:
Um caminho de execução dentro de um processo Compartilha a mesma memória do processo pai Muito mais "leve" que um processo (por isso chamada de processo leve )
Múltiplas threads podem executar dentro do mesmo processo
Visualização:
PROCESSO CHROME (o "mundo") ├─ Espaço de memória compartilhado: 500 MB │ ├─ Thread 1: Renderiza páginas web │ └─ Stack próprio: 1 MB │ ├─ Thread 2: Baixa arquivos │ └─ Stack próprio: 1 MB │ └─ Thread 3: Executa JavaScript └─ Stack próprio: 1 MB
Total usado: 503 MB (muito menos que 3 processos separados!)
Threads compartilham:
Código do programa Dados globais (variáveis compartilhadas) Arquivos abertos Sinais e conexões de rede
Mas cada thread tem seu próprio:
Stack (pilha de execução) - área de memória exclusiva Registradores Program Counter (PC) - indica onde está no código Estado de execução
CAPÍTULO 2: PARALELISMO VS. CONCORRÊNCIA
2.1 Sistema Single-Core (Concorrência)
"Em um single-core, as threads executam alternadamente (time-sharing). CPU Única, com Multiprogramação. Múltiplas tarefas ALTERNANDO rapidamente. Parece simultâneo, mas NÃO É!"
Exemplo didático - Garçom único:
🕐 15:00 - Atende Mesa 1 (Thread 1) 🕐 15:01 - Atende Mesa 2 (Thread 2) 🕐 15:02 - Atende Mesa 3 (Thread 3)
Exemplo prático - Servidor Web:
SEM THREADS (Sequencial):
Thread 1: Atende Cliente 1 → Lê arquivo → Envia resposta (3s) DEPOIS Atende Cliente 2 → Busca BD → Envia resposta (2s) DEPOIS Atende Cliente 3 → Processa imagem → Envia resposta (4s)
TEMPO TOTAL: 9 segundos ❌
COM THREADS (Paralelo em multi-core):
Thread 1: Atende Cliente 1 → Lê arquivo → Envia resposta (3s) Thread 2: Atende Cliente 2 → Busca BD → Envia resposta (2s) ← AO MESMO TEMPO Thread 3: Atende Cliente 3 → Processa imagem → Envia resposta (4s)
TEMPO TOTAL: 4 segundos ✅ (tempo da thread mais lenta)
SPEEDUP: 2.25x mais rápido!
3.2 Otimização de Recursos
Comparação visual - Uso de memória:
OPÇÃO 1: 3 PROCESSOS SEPARADOS
Processo Chrome 1: ├─ Memória: 200 MB ├─ Código: 50 MB ├─ Recursos: 30 MB └─ Total: 280 MB
Processo Chrome 2: ├─ Memória: 200 MB ├─ Código: 50 MB (DUPLICADO!) ├─ Recursos: 30 MB └─ Total: 280 MB
Processo Chrome 3: ├─ Memória: 200 MB ├─ Código: 50 MB (DUPLICADO!) ├─ Recursos: 30 MB └─ Total: 280 MB
CUSTO TOTAL: 840 MB ❌
OPÇÃO 2: 1 PROCESSO COM 3 THREADS
Processo Chrome (compartilhado): ├─ Memória: 200 MB (COMPARTILHADA) ├─ Código: 50 MB (COMPARTILHADO) ├─ Recursos: 30 MB (COMPARTILHADOS) ├─ Thread 1: + 1 MB (stack próprio) ├─ Thread 2: + 1 MB (stack próprio) └─ Thread 3: + 1 MB (stack próprio)
CUSTO TOTAL: 283 MB ✅
ECONOMIA: ~66% menos memória!
CAPÍTULO 4: CICLO DE VIDA DAS THREADS
Estados de uma Thread:
- NOVO ├─ Thread criada, mas não iniciada └─ Aguardando start()
- PRONTO/EXECUTÁVEL ├─ Thread pronta para executar └─ Aguardando CPU disponível
3. EM EXECUÇÃO
├─ Thread está executando na CPU └─ Processando instruções
← Stack independente do Funcionário 1
Funcionário 3 (Thread 3) - Executando JavaScript: 📔 SEU BLOCO DE NOTAS (STACK): Página 4: função alert() Página 3: função processar_evento() Página 2: função executar_script() Página 1: função iniciar_js() ← Stack próprio, não interfere com outros
Por que cada thread precisa de stack próprio?
Para não confundir as anotações (cada um sabe onde parou) Para permitir execução simultânea sem con itos Para manter variáveis locais independentes Para controlar chamadas de funções de forma isolada
CAPÍTULO 6: EVOLUÇÃO HISTÓRICA - POR QUE THREADS EXISTEM?
6.1 Anos 1960-1970: O Caos Sem Proteção
"Antigamente a duplicação era comum, cada programa tinha sua cópia isolada."
"Um programa podia DESTRUIR, MODIFICAR ou CORROMPER os dados de outro programa!"
Exemplo do problema:
CENÁRIO ANOS 1960:
Programa A (Calculadora): ├─ Usa endereços: 1000- └─ Armazena resultado em 1500
Programa B (Editor): ├─ Deveria usar: 3000- └─ MAS hardware não impede acesso!
PROBLEMA:
- Programa B tem um bug
- Tenta escrever em endereço 1500 (de A!)
- Corrompe o resultado da calculadora
- Calculadora mostra: 2 + 2 = "texto aleatório" ❌
CAUSA: Hardware não tinha proteção de memória!
Por que acontecia:
HARDWARE PRIMITIVO: ❌ Sem MMU (Memory Management Unit) ❌ Sem endereços virtuais ❌ Sem proteção de memória ❌ Qualquer programa acessava qualquer endereço
= CAOS TOTAL!
6.2 Anos 1980-1990: Compartilhamento Controlado
Solução moderna: Threads com proteção
HOJE: Compartilhamento SEGURO
Processo Chrome: ├─ Endereços virtuais protegidos pela MMU ├─ Thread 1, 2, 3: compartilham memória COM SEGURANÇA └─ Outros processos NÃO conseguem acessar!
Processo Word: ├─ Endereços virtuais SEPARADOS do Chrome └─ Isolamento total entre processos ✅
RESULTADO: ✅ Threads compartilham dentro do processo ✅ Processos são isolados entre si
CAPÍTULO 7: MUTEX - SINCRONIZAÇÃO DE THREADS
7.1 O Problema: Race Condition
Exemplo didático - Contador compartilhado:
CENÁRIO: 2 threads incrementando contador
contador = 0
Importante: O programador DEVE implementar mutex manualmente no código! Não é automático!
PARTE II: GERENCIAMENTO DE MEMÓRIA
CAPÍTULO 8: CONEXÃO ENTRE THREADS E MEMÓRIA
Como threads e gerenciamento de memória se relacionam:
FATO FUNDAMENTAL: Todas as threads de um processo COMPARTILHAM o mesmo espaço de memória
IMPLICAÇÕES:
├─ Threads acessam os mesmos dados na RAM ├─ Mais threads = mais pressão sobre a memória ├─ Mais threads = mais page faults potenciais └─ Gerenciamento eficiente é CRUCIAL!
EXEMPLO: Processo Chrome com 10 threads: ├─ Todas acessam os mesmos 500 MB de RAM ├─ Todas competem pelos mesmos frames └─ Sistema precisa gerenciar acesso de todas
CAPÍTULO 9: MEMÓRIA VIRTUAL - CONCEITO BÁSICO
9.1 O Problema
Como executar programa de 12 GB em computador com 8 GB de RAM?
CENÁRIO IMPOSSÍVEL (sem memória virtual): ├─ Programa: 12 GB ├─ RAM disponível: 8 GB └─ Resultado: "Memória insuficiente" ❌
CENÁRIO POSSÍVEL (com memória virtual): ├─ Programa: 12 GB ├─ RAM disponível: 8 GB ├─ Disco usado como extensão: 4 GB └─ Resultado: Programa executa! ✅
9.2 Analogia Didática: Mesa e Estante
"Imagine que seu cérebro (CPU) quer lembrar de algo guardado na sua mesa (RAM): Ele procura e... não está lá! Tem que levantar, buscar na estante (HD/SSD) e trazer para a mesa. Esse 'levantar e buscar' leva tempo — é o que causa a lentidão."
VOCÊ = CPU MESA = RAM (8 GB) - espaço limitado ESTANTE = DISCO (1 TB) - espaço grande mas lento
CENÁRIO: Estudar 100 livros
SEM MEMÓRIA VIRTUAL: ❌ Mesa cabe 10 livros ❌ "Não consigo estudar os outros 90" ❌ Tarefa impossível
COM MEMÓRIA VIRTUAL: ✅ Coloca 10 livros na mesa (mais importantes) ✅ Outros 90 ficam na estante ✅ Quando precisa do livro 11:
- Guarda livro menos usado na estante
- Pega livro 11 da estante
- Coloca na mesa
- Continua estudando ✅ Consegue usar TODOS os 100 livros!
CUSTO: Ir à estante é 100.000x mais lento que pegar da mesa
9.3 Como Funciona Tecnicamente
Programa de 12 GB rodando em RAM de 8 GB:
. O sistema operacional divide o programa em pequenas partes chamadas páginas (geralmente 4 KB cada)
Programa: 12 GB ÷ 4 KB por página = 3.145.728 páginas
. Mantém apenas as páginas mais usadas na RAM
RAM (8 GB): ~2 milhões de páginas (as ATIVAS)
. Move páginas menos usadas para o disco (área de swap/paginação)
ANDAR 2:
[Apto 4: Página D] [Apto 5: Vazio] [Apto 6: Página E]
CARACTERÍSTICAS: ✅ Total de apartamentos: fixo (2 milhões) ✅ Cada apartamento: 4 KB ✅ Páginas de programas diferentes podem ser vizinhas ✅ Quando não há vagas: alguém deve sair (algoritmo decide!)
10.4 Tamanho das Páginas
"Onde é de nido o tamanho das páginas? De nido pela arquitetura do processador (hardware)"
DEFINIÇÃO POR HARDWARE:
Intel x86/x86_64: └─ Padrão: 4 KB
ARM64: └─ Pode ser: 4 KB, 16 KB ou 64 KB
Sistemas especiais: └─ "Huge pages": 2 MB ou mais
POR QUE 4 KB É POPULAR? ✅ Bom equilíbrio entre eficiência e overhead ✅ Fragmentação interna baixa ✅ Funciona bem para maioria dos programas
CAPÍTULO 11: PAGE FAULT - QUANDO A PÁGINA NÃO ESTÁ NA RAM
11.1 De nição
"Page fault (falta de página) ocorre quando o programa tenta acessar uma informação que não está na RAM naquele momento."
11.2 O Que Acontece Durante um Page Fault
PASSO A PASSO:
- Programa solicita página que não está na RAM
Exemplo: Thread do Chrome precisa de dados do minuto 30 do vídeo
- MMU detecta: "Essa página está no DISCO!" (page fault) MMU gera interrupção para o SO
- Sistema Operacional: ├─ Pausa o programa/thread temporariamente ├─ Remove uma página antiga da RAM (usando algoritmo) ├─ Carrega a página solicitada do disco para a RAM └─ Atualiza a tabela de páginas
- Programa continua executando normalmente Thread consegue acessar os dados!
Importante:
Programa NÃO PERCEBE que usa disco (endereços virtuais escondem isso) Page faults são normais , mas muitos page faults causam lentidão
11.3 Exemplo Completo: Editando Vídeo
SITUAÇÃO: Você clica no minuto 30 do vídeo no Premiere
1. SOLICITAÇÃO:
Thread: "Quero frame do minuto 30!"
2. VERIFICAÇÃO:
MMU: "Página está no disco!" (page fault) 🚨
- SO PAUSA A THREAD: "Não pode continuar sem esses dados..."
- SO DECIDE: Algoritmo LRU: "Página do minuto 5 é a menos usada"
- SO FAZ A TROCA: ├─ Salva página do minuto 5 → disco (500ms) └─ Carrega página do minuto 30 → RAM (500ms)
- SO ATUALIZA TABELA: "Minuto 30 agora está na RAM!"
"Decidir qual página remover da RAM para dar lugar a uma nova página quando:
Todos os frames estão ocupados E Ocorre um page fault"
Objetivo:
Minimizar o número de page faults Manter as páginas mais úteis na RAM Evitar trazer páginas do disco frequentemente"
13.2 Cenário Base para Exemplos
CONFIGURAÇÃO DO TESTE: ├─ RAM: 3 frames disponíveis ├─ Sequência solicitada: 1, 3, 0, 3, 5, 6, 3 └─ Objetivo: contar page faults
LEGENDA: ✅ = Página já na RAM (sem page fault) ❌ = Page fault (busca do disco)
CAPÍTULO 14: ALGORITMO FIFO - EXEMPLO DETALHADO
"FIFO = First-In-First-Out (primeiro que entra, primeiro que sai)"
Rastreia: ordem de chegada ( la) Decide: remover página mais antiga Pergunta: "Quem chegou primeiro?"
Execução Passo a Passo:
Passo 1: Solicita 1 RAM: [1] [ ] [ ] Fila: 1 (chegou primeiro) Page fault: ❌ (1º)
Passo 2: Solicita 3 RAM: [1] [3] [ ] Fila: 1, 3 (1 ainda é o mais antigo) Page fault: ❌ (2º)
Passo 3: Solicita 0 RAM: [1] [3] [0] Fila: 1, 3, 0 (RAM cheia!) Page fault: ❌ (3º)
Passo 4: Solicita 3 RAM: [1] [3] [0] Fila: não muda (3 já está!) Page fault: ✅ SEM FALHA
Passo 5: Solicita 5 RAM: [5] [3] [0] Fila: remove 1 (mais antigo), adiciona 5 Page fault: ❌ (4º)
Passo 6: Solicita 6 RAM: [5] [6] [0] Fila: remove 3 (agora mais antigo), adiciona 6 Page fault: ❌ (5º)
Passo 7: Solicita 3 RAM: [5] [6] [3] Fila: remove 0 (agora mais antigo), adiciona 3 Page fault: ❌ (6º)
RESULTADO FIFO: 6 page faults EFICIÊNCIA: 1/7 = 14%
Desvantagem: Pode remover página que será usada em breve!
CAPÍTULO 15: ALGORITMO LRU - EXEMPLO DETALHADO
"LRU = Least Recently Used (menos usado recentemente)"
Rastreia: último tempo de acesso Decide: remover página não usada há mais tempo Pergunta: "Quem não foi usado há mais tempo?"
Execução Passo a Passo:
Passo 1: Solicita 1 RAM: [1] [ ] [ ]
Vantagem: Excelente performance Desvantagem: Complexo de implementar, requer hardware especial Usado em: Linux, Windows, praticamente todos os SO modernos
CAPÍTULO 16: OUTROS ALGORITMOS
OPTIMAL (Ótimo)
Rastreia: futuro (impossível!) Decide: remover página usada mais longe no futuro Pergunta: "Quem será usado mais tarde?"
Vantagem: Melhor performance teórica possível Desvantagem: IMPOSSÍVEL implementar (exigiria saber o futuro) Usado em: Apenas como benchmark para comparar outros algoritmos
CLOCK (Second-Chance)
Rastreia: reference bit circular Decide: remover página com reference bit = 0 Pergunta: "Quem tem bit = 0?"
Como funciona:
Estrutura circular com ponteiro:
[A:bit=1] ↑ [C:bit=0] ← PONTEIRO → [B:bit=1] ↓ [D:bit=0]
Algoritmo:
- Verifica página no ponteiro
- Se bit = 1: limpa para 0, move ponteiro
- Se bit = 0: REMOVE essa página!
Páginas usadas recentemente ganham "segunda chance"
Vantagem: Performance quase tão boa quanto LRU, fácil de implementar Usado em: Linux, Windows
LFU (Least Frequently Used)
Rastreia: contagem de acessos Decide: remover página com menor contagem Pergunta: "Quem foi usado menos vezes?"
Vantagem: Funciona bem para padrões estáveis Desvantagem: Pode car "preso" com páginas antigas Usado em: Raríssimo em SO modernos
MRU (Most Recently Used)
Rastreia: último tempo de acesso Decide: remover página MAIS usada recentemente Pergunta: "Quem foi usado DEMAIS recentemente?"
Vantagem: Casos especí cos (scanning sequencial) Desvantagem: Performance péssima na maioria dos casos Usado em: Muito raro
CAPÍTULO 17: THRASHING - QUANDO TUDO DÁ ERRADO
17.1 De nição
"Situação em que o sistema está constantemente movendo páginas entre RAM e disco, sem conseguir executar os programas de fato."
17.2 Por Que Acontece
"Não há frames su cientes para manter a 'working set' (conjunto de páginas mais usadas) de todos os processos ativos. Qualquer algoritmo vai remover páginas que logo depois serão necessárias novamente."
17.3 Exemplo Real: 50 Abas no Chrome
CENÁRIO CATASTRÓFICO:
Você abre: ├─ 50 abas no Chrome ├─ Photoshop com imagem grande └─ Excel com planilha pesada
