Pular para o conteúdo principal

Aula 1: Introdução e Estruturas dos Sistemas Operacionais

Objetivos​

  • Definir o papel de um Sistema Operacional na arquitetura de um sistema de computação
  • Descrever a hierarquia de armazenamento e o papel do DMA na transferência de dados
  • Listar os principais serviços fornecidos pelo SO e associá-los a suas responsabilidades
  • Explicar o mecanismo de chamadas de sistema e distinguir API de chamada de sistema
  • Comparar as arquiteturas internas de kernel: monolítico, em camadas, microkernel e híbrido
  • Descrever o processo de bootstrapping desde a energização até a carga do kernel

Conteúdo​

1. O que é e o que faz um Sistema Operacional? (Ref: Cap. 1.1)​

Um sistema de computação pode ser grosseiramente dividido em quatro componentes: o hardware, o sistema operacional, os programas aplicativos e os usuários. O livro-texto traça uma analogia muito interessante: um sistema operacional é semelhante a um governo. Por si só, o SO não executa nenhuma função útil; ele não edita textos nem calcula planilhas. Seu papel é fornecer um ambiente no qual outros programas possam desempenhar tarefas úteis de forma ordenada e segura.

A visão que se tem do SO depende de quem está olhando:

  • A Perspectiva do Usuário: Para o usuário final sentando diante de um PC, o foco absoluto é a facilidade de uso e o desempenho individual. O sistema é otimizado para que essa única pessoa monopolize os recursos. Em contraste, usuários acessando um mainframe por terminais necessitam que o SO atue maximizando a utilização, garantindo que ninguém ocupe mais CPU ou memória do que sua cota. Já nos dispositivos móveis (smartphones), o foco muda para interfaces sensíveis ao toque (toque, gestos) e forte restrição de consumo de energia.
  • A Perspectiva do Sistema: O hardware enxerga o SO como o seu gerente íntimo. Ele é um alocador de recursos, lidando com solicitações numerosas e conflitantes de tempo de CPU, espaço em disco e memória. Ele também é um programa de controle, encarregado de domar os programas de usuário para evitar erros (como tentar escrever em uma área de memória proibida) e o uso impróprio dos dispositivos de E/S.

2. A Arquitetura de Hardware Subjacente (Ref: Cap. 1.2)​

Um SO não pode ser compreendido sem entender o hardware que ele governa. O ciclo básico de execução de instruções (Arquitetura de von Neumann) envolve buscar uma instrução na memória principal, armazená-la no registrador de instruções, decodificá-la e executá-la.

O grande gargalo da computação é a diferença de velocidade entre a CPU e os dispositivos de armazenamento. Por isso, existe a Hierarquia de Armazenamento: No topo, temos os registradores e a memória cache (minúsculos, caríssimos e operando na velocidade da CPU). Logo abaixo, a Memória Principal (RAM), que é o único grande dispositivo de armazenamento que a CPU consegue endereçar diretamente. O problema da RAM é que ela é volátil (perde os dados sem energia) e pequena demais para guardar todos os programas. Por isso, usamos a memória secundária (discos magnéticos e de estado sólido/SSD), que é não-volátil.

O papel do Acesso Direto à Memória (DMA): Dispositivos de E/S (como discos) são muito lentos. Se a CPU tivesse que transferir cada byte do disco para a RAM, ela ficaria ociosa a maior parte do tempo. O SO configura o controlador de DMA para que o próprio dispositivo transfira blocos inteiros de dados diretamente para a RAM. A CPU é liberada para fazer outras coisas e só é interrompida (uma única interrupção por bloco) quando a transferência termina.

3. Serviços do Sistema Operacional (Ref: Cap. 2.1)​

Para facilitar a vida do programador, o SO abstrai a complexidade do hardware fornecendo um catálogo de serviços:

  • Execução e E/S: O SO é responsável por alocar a memória, carregar o código binário do disco e gerenciar as operações de I/O (já que, por segurança, usuários não podem acessar diretamente um controlador de disco).
  • Manipulação de Arquivos: O conceito de "arquivo" e "diretório" não existe no hardware; o disco só enxerga blocos magnéticos ou células de silício. O SO cria essa abstração lógica, permitindo ler, gravar, buscar e gerenciar permissões de acesso.
  • Comunicações: Processos precisam trocar dados. O SO implementa isso de duas formas: Memória Compartilhada (onde dois processos leem e gravam numa mesma região de RAM) ou Transmissão de Mensagens (onde o SO empacota a informação e a move entre os processos, muito útil em sistemas distribuídos).
  • Detecção de Erros e Proteção: O SO deve reagir a divisões por zero, estouros de memória, falta de papel na impressora ou falhas de rede, sem deixar o sistema inteiro cair. Ele usa o isolamento de recursos para proteger processos uns dos outros.

4. Chamadas de Sistema (System Calls) e APIs (Ref: Cap. 2.3)​

Como um programa solicita algo ao SO? Através das Chamadas de Sistema. O livro ilustra isso com um exemplo prático: um simples programa que copia dados de um arquivo para outro. Para fazer isso, o programa precisa fazer dezenas de chamadas: capturar a entrada do usuário (nome do arquivo), chamar o SO para verificar se o arquivo existe, chamar o SO para criar o arquivo de destino, lidar com erros (e se o arquivo de destino já existir?), fazer um loop de leitura e gravação (chamando o SO a cada bloco) e finalmente fechar os arquivos.

Para que os programadores não enlouqueçam lidando com interrupções de hardware, foram criadas as APIs (Application Programming Interfaces). As mais famosas são a API POSIX (usada em UNIX/Linux/Mac), a API Win32 (Windows) e a API Java. Quando você programa em C e usa a função printf(), você não está chamando o SO. Você está chamando uma função da biblioteca C (libc). Essa biblioteca pega seus dados e, nos bastidores, invoca a verdadeira chamada de sistema (como a chamada write() no UNIX).

Passagem de Parâmetros: Para a chamada de sistema funcionar, o SO precisa de dados. Se os dados forem poucos, são passados pelos registradores da CPU. Se forem muitos, são guardados em uma tabela/bloco na memória, e o endereço desse bloco é passado por um registrador (técnica usada pelo Linux). Uma terceira opção é empilhar (push) os dados na pilha do sistema, para que o SO os desempilhe (pop).

5. Arquitetura Interna do Sistema Operacional (Ref: Cap. 2.7)​

Ao longo das décadas, o design interno (kernel) dos SOs evoluiu para lidar com a crescente complexidade:

  • Sistemas Monolíticos (A Estrutura Simples): Todo o SO roda no mesmo espaço de memória, como um único e gigantesco programa. O MS-DOS original era assim, tão simples que aplicativos podiam acessar o disco diretamente, burlando o SO (o que causava travamentos constantes). O UNIX original também era monolítico. A vantagem é o desempenho brutal (não há overhead de comunicação entre partes do SO). A desvantagem é que, se um componente falhar (como um driver de vídeo), a máquina inteira sofre uma "tela azul" (Kernel Panic).
  • Abordagem em Camadas: Para organizar a bagunça, tentou-se dividir o SO em camadas estritas (Camada 0 = Hardware, Camada N = Interface de Usuário). Uma camada só pode usar os serviços da camada inferior. É excelente para debugar: se a camada 1 funciona, o erro só pode estar na 2. Porém, é lento. Uma chamada de rede precisa atravessar dezenas de camadas até chegar ao hardware.
  • Microkernels: Criado pela Universidade Carnegie Mellon (sistema Mach). A ideia genial aqui é retirar tudo o que não é essencial do Kernel e rodar como "programas de usuário". O microkernel gerencia apenas a CPU, a memória básica e a comunicação. Se o driver do sistema de arquivos der erro, ele quebra como um aplicativo comum, sem derrubar o PC. O problema? É lento, pois exige que os processos troquem milhares de mensagens através do microkernel o tempo todo (O Windows NT tentou ser assim no começo, mas abandonou a ideia por causa do baixo desempenho).
  • Módulos Carregáveis e Sistemas Híbridos: É a solução moderna (Linux, Solaris, MacOS, Windows moderno). O kernel é monolítico para manter a velocidade, mas é modular. O SO pode carregar "Módulos de Kernel" (como um driver para um novo pendrive) enquanto o sistema está rodando, sem precisar recompilar o kernel ou reiniciar a máquina. O MacOS X (Darwin) é o maior exemplo híbrido: usa o microkernel Mach na base, acoplado ao kernel monolítico do BSD UNIX para garantir velocidade.

6. Ambientes de Computação (Ref: Cap. 1.11)​

A aplicação dos SOs mudou conforme o hardware se diversificou:

  • Computação Móvel: Sistemas como Android e iOS lidam com restrições severas. Processadores menores, limitação de bateria e sensores novos (GPS, acelerômetros, giroscópios para Realidade Aumentada).
  • Sistemas Distribuídos (Redes e Clusters): Vários computadores fisicamente separados que se comunicam. Pode ser um modelo Cliente-Servidor (um servidor central fornecendo arquivos/computação) ou Peer-to-Peer / P2P (todos os nós são clientes e servidores ao mesmo tempo, como o antigo Napster ou o protocolo do Skype). Os Clusters unem vários computadores para trabalharem no mesmo problema (alta performance) ou para garantir que, se um servidor queimar, o outro assume imediatamente (alta disponibilidade).
  • Virtualização: É a tecnologia que permite rodar o Windows como um "aplicativo" dentro do MacOS. Um programa chamado VMM (Virtual Machine Manager ou Hypervisor, como o VMware) atua como um falso hardware, enganando o SO convidado. É a base de toda a Computação em Nuvem moderna (Amazon AWS, Google Cloud).
  • Sistemas de Tempo Real: Computadores embutidos em freios de carros, marca-passos médicos ou braços robóticos. Neles, o SO não é focado em "interface bonita", mas em restrições de tempo rígidas. Se um robô operário atrasar 1 segundo para processar um dado, ele esmaga o chassi de um carro. O processamento tem que ser garantido.

7. Bootstrapping: Como o sistema "nasce" (Ref: Cap. 2.10)​

Quando você liga o computador, a memória RAM está limpa e vazia. A CPU não sabe o que fazer. Para resolver isso, a placa-mãe possui um chip de memória não-volátil (ROM ou EEPROM), contendo um pequeno código chamado Firmware (como a BIOS ou UEFI). A CPU é programada via hardware para ler esse chip ao ser energizada. Esse programa inicial, chamado Bootstrap, faz um diagnóstico da máquina e procura o disco rígido. Como os SOs modernos pesam gigabytes, o Bootstrap não carrega o SO inteiro. Ele vai até o primeiro setor do disco rígido (o Bloco Zero ou Bloco de Inicialização), onde existe um pequeno programa chamado Bootloader (como o GRUB no Linux). O Bootloader então navega pelos arquivos do disco, encontra o arquivo binário contendo o núcleo (Kernel) do SO, carrega-o para a RAM e diz à CPU: "A partir de agora, o Sistema Operacional está no comando".

Exercícios (Checkpoints)​

  1. O livro-texto compara o SO a um governo. Explique essa analogia e indique duas limitações dela.
  2. Um programa em C chama printf("Olá"). Essa chamada interage diretamente com o hardware? Trace o caminho percorrido até os dados aparecerem na tela.
  3. Explique o papel do DMA. Por que sem ele a CPU ficaria ociosa durante operações de leitura de disco?
  4. Qual a diferença entre a perspectiva do usuário de PC e do usuário de mainframe em relação ao que se espera do SO?
  5. Compare as arquiteturas monolítica e microkernel: cite uma vantagem e uma desvantagem de cada uma.
  6. O macOS usa uma arquitetura híbrida (Mach + BSD). Que benefício essa combinação oferece em relação a adotar apenas um dos dois designs?
  7. Descreva, em ordem, as etapas do bootstrapping desde o momento em que o computador é ligado até o kernel assumir o controle.

Referências​

Principais​

  • SILBERSCHATZ, Abraham; GALVIN, Peter Baer; GAGNE, Greg. Operating System Concepts. 10. ed. Wiley, 2018. Cap. 1 e 2.

Aprofundamento​