Sistemas Operacionais

O que é este tópico

Sistemas Operacionais estuda o software que fica entre o hardware e os seus programas: como o SO gerencia processos, memória, arquivos e dispositivos, e como oferece a ilusão de que cada programa tem a máquina inteira só pra si. É a disciplina que explica o que realmente acontece quando você “roda um programa”.

Por que estudar isso?

Situação que todo desenvolvedor vive: o servidor está lento, top mostra CPU em 40% — então por que a lentidão? Quem estudou SO sabe onde olhar: processos bloqueados em E/S, swap sendo usado porque a RAM acabou, excesso de trocas de contexto, um processo zumbi acumulando. Sem esse modelo mental, “está lento” é um mistério; com ele, é um diagnóstico com passos concretos.

Além do diagnóstico, SO é onde você finalmente entende os conceitos que usa todo dia sem ver: o que é de fato um processo e uma thread, por que seu programa multithread dá resultado diferente a cada execução (condição de corrida), o que significa aquele “segmentation fault”. E há o efeito colateral profissional: estudar SO na prática significa dominar Linux e sua linha de comando — que é o ambiente onde roda a esmagadora maioria dos servidores, da nuvem e dos sistemas embarcados que você vai encontrar na carreira.

Trilha de estudo

1. Linux e linha de comando (3–4 semanas)

O que dominar: navegar e manipular arquivos pelo terminal, permissões, redirecionamento e pipes, gerenciar processos (ps, top, kill), e o layout de diretórios do Linux. O que praticar: usar Linux como sistema do dia a dia (ou WSL) e se forçar a resolver tarefas pelo terminal. SO se estuda de dentro de um SO.

2. Processos e threads (4–6 semanas)

O que dominar: o que compõe um processo (espaço de endereçamento, descritores, estado), ciclo de vida, criação (fork/exec no Unix), threads vs. processos, troca de contexto e os algoritmos de escalonamento (FIFO, SJF, Round Robin, prioridades). O que praticar: escrever programas pequenos em C usando fork, observar PIDs e estados no ps, e simular escalonamentos à mão em exercícios.

3. Concorrência e sincronização (4–6 semanas)

O que dominar: condições de corrida, seções críticas, mutex, semáforos, deadlock (condições e tratamento) e os problemas clássicos (produtor-consumidor, jantar dos filósofos). O que praticar: provocar uma condição de corrida de propósito com duas threads incrementando um contador — ver o bug acontecer e depois consertá-lo com mutex é a aula que fica.

4. Memória, arquivos e E/S (6–8 semanas)

O que dominar: memória virtual e paginação (agora do lado da política: algoritmos de substituição, thrashing), sistemas de arquivos (inodes, diretórios, journaling) e gerência de E/S. O que praticar: explorar /proc, medir uso de memória real vs. virtual de processos, e acompanhar chamadas de sistema de um comando com strace pra ver o SO trabalhando ao vivo.

Conceitos que você precisa dominar

• Processo — Um programa em execução: o código mais seu estado (memória, registradores, arquivos abertos). O SO mantém dezenas ou centenas deles, cada um acreditando ter a máquina inteira. Entender o que é um processo é entender a unidade básica de tudo que o SO gerencia — e o que comandos como kill e ps realmente manipulam.
• Thread e troca de contexto — Threads são fluxos de execução dentro de um mesmo processo, compartilhando memória. A troca de contexto — salvar o estado de um fluxo e restaurar o de outro — é o truque que cria a ilusão de simultaneidade num único núcleo, e tem custo real: trocas demais degradam o sistema (e explicam parte daquele servidor “lento com CPU sobrando”).
• Chamadas de sistema (syscalls) — A única porta de entrada do seu programa pro kernel: abrir arquivo, criar processo, alocar memória, enviar pela rede — tudo vira syscall. A separação modo usuário/modo kernel que elas atravessam é o mecanismo central de proteção do sistema. strace mostra essa fronteira ao vivo.
• Condição de corrida e exclusão mútua — Quando duas threads acessam o mesmo dado e pelo menos uma escreve, o resultado depende da ordem de execução — que é imprevisível. É a classe de bug mais difícil de depurar que existe, porque some quando você observa. Mutex e semáforos são as ferramentas de exclusão mútua; usá-los corretamente é habilidade obrigatória, não avançada.
• Deadlock — Duas ou mais threads esperando recursos que a outra segura, pra sempre. Acontece quando quatro condições se combinam (exclusão mútua, posse-e-espera, não preempção, espera circular) — e a engenharia está em quebrar uma delas, tipicamente ordenando a aquisição de locks. Todo sistema concorrente de verdade já enfrentou isso.
• Memória virtual e paginação — Cada processo enxerga um espaço de endereços próprio e contíguo; o SO mapeia páginas virtuais em quadros físicos, jogando pra disco o que não cabe (swap). Explica como 20 programas “usando 2 GB cada” rodam em 16 GB de RAM — e o que é thrashing, quando o sistema passa mais tempo paginando que executando.
• Escalonamento — A política que decide qual processo usa a CPU agora. Cada algoritmo otimiza uma coisa diferente: throughput, tempo de resposta, justiça. Entender os trade-offs explica comportamentos visíveis — por que um sistema interativo prefere Round Robin, por que processo de E/S intensiva ganha prioridade na prática.
• Sistema de arquivos — A estrutura que transforma blocos brutos de disco em arquivos e diretórios com nomes, permissões e metadados. Conceitos como inode explicam coisas concretas do dia a dia: por que renomear é instantâneo mas copiar não, o que é um hard link, por que “deletar” não apaga os dados imediatamente.

Erros comuns de quem está começando

• Estudar SO só na teoria, sem terminal — Decorar estados de processo sem nunca rodar ps ou explorar /proc produz conhecimento que evapora após a prova. Cada conceito da disciplina tem um comando que o torna observável; use o Linux como laboratório permanente.
• Achar que concorrência é tópico avançado ignorável — Todo software moderno é concorrente: servidores web, interfaces gráficas, apps mobile. Quem adia o entendimento de condição de corrida e mutex escreve bugs intermitentes que não sabe nem reproduzir, quanto mais consertar.
• Testar programa concorrente “algumas vezes” e concluir que funciona — Condição de corrida pode aparecer uma vez a cada dez mil execuções. Ausência de falha no teste não é prova de correção; a garantia vem do raciocínio sobre as seções críticas, não da repetição.
• Confundir memória virtual com swap — Memória virtual é o mecanismo de tradução de endereços que existe sempre, mesmo com RAM sobrando; swap é só o transbordo pra disco. Misturar os dois impede de entender tanto o desempenho quanto as ferramentas de diagnóstico (free, vmstat).
• Tratar o “matar processo” como solução, não como sintoma — kill -9 resolve o momento, mas quem para aí nunca aprende. O hábito profissional é perguntar por que o processo travou: bloqueado em quê? esperando qual recurso? Os conceitos da disciplina são exatamente o vocabulário dessa pergunta.

📚 Materiais recomendados

Livros e apostilas abertas

• Sistemas Operacionais (Rede e-Tec/IFRO) — apostila aberta em português cobrindo processos, memória e arquivos no nível introdutório. Disponível no portal público proedu.rnp.br.
• Sistemas Operacionais II (Rede e-Tec) — continuação, avançando em gerência de memória e estudo de casos. Também via proedu.rnp.br.
• Introdução ao Linux (Escola Técnica Aberta) — apoio direto à etapa 1 da trilha: terminal, comandos e administração básica. Também via proedu.rnp.br.

Bibliografia clássica (consultar na biblioteca)

• TANENBAUM, A. S. Sistemas Operacionais Modernos. — A referência mundial da disciplina: processos, memória, arquivos, E/S e estudos de caso (Linux, Windows). É o livro pra aprofundar cada etapa desta trilha.

🔗 Referências externas

• Roadmap: Linux — trilha de domínio do Linux, do básico de terminal à administração; acompanha a etapa 1 e continua útil a carreira inteira.
• man7.org — as man pages do Linux mantidas por Michael Kerrisk: a documentação definitiva de syscalls e da API do sistema. Use quando quiser saber exatamente o que fork, mmap ou qualquer chamada faz.
• kernel.org — a fonte oficial do kernel Linux, com documentação. Menos pra ler linearmente, mais pra saber onde mora a verdade quando a dúvida é profunda.
• MIT OpenCourseWare — procure “Operating System Engineering” (6.828/6.1810): curso em que se estuda e estende um SO de verdade. Avançado, mas referência pra quem quiser ir além da ementa.
• CS50 — Harvard — as aulas de C e memória são um bom pré-requisito informal pra etapa 2: você precisa estar confortável com ponteiros antes de estudar fork e memória virtual.

Conexão com as disciplinas do curso

• Sistemas Operacionais I — etapas 1 a 3 da trilha: processos, threads, escalonamento e sincronização.
• Sistemas Operacionais II — etapa 4: memória virtual, sistemas de arquivos e E/S.