Sistemas Operacionais 1 - Notas de Aula

Sistemas Operacionais 1 - Resumo
Prof. Ricardo Pinheiro
23/04/2010
Sumário
1 Introdução 4
1.1 O que é um Sistema Operacional (SO)? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Funções: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Máquina de Níveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Tipos de Sistemas Operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Sistemas Monotarefa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Sistemas Multitarefa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2.1 Lote ou Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2.2 Tempo Compartilhado (Time-Share) . . . . . . . . . . . . . . . . . . . . . 6
1.3.2.3 Tempo Real (Real-Time) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Multiplas UCP´s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3.1 Multiprocessadores, ou sistemas fortemente acoplados . . . . . . . . . . . 7
1.3.3.2 Multicomputadores, ou sistemas fracamente acoplados. . . . . . . . . . . . 8
2 Concorrência 9
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Interrupções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Exceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Controladoras de E/S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 No início... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 E/S Controlada por Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.4 E/S Controlada por Interrupção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.5 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.5.1 Canal DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Spooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Reentrância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Proteção do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Estrutura do sistema operacional 14

3.1 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Chamadas do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Utilitários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Modos de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1
SUMÁRIO 2
3.5 Tipos de kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5.1 Monolítico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.2 Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.3 Máquina Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.4 Microkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Processos e threads 19
4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Partes do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Bloco de controle do processo (PCB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Estados do processo e mudanças de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1 Mudanças de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Criação e eliminação de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Concorrência dentro de uma aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Tipos de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8 Sinais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.9 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9.2 Ambientes monothread e multithread . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9.2.1 Monothread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9.2.2 Multithread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.9.3 Formas de implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.9.3.1 Threads em Modo Usuário (TMU) . . . . . . . . . . . . . . . . . . . . . . 23
4.9.3.2 Threads em Modo Kernel (TMK) . . . . . . . . . . . . . . . . . . . . . . . 23
4.9.3.3 Threads em Modo Híbrido (TMH) . . . . . . . . . . . . . . . . . . . . . . 24
4.9.3.4 Scheduler activations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Sincronização entre processos 25

5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Concorrência no código fonte: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 Comandos FORK e JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1.1 Como funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.2 ParBegin e ParEnd (CoBegin e CoEnd) . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.1 Como funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Exemplos de problemas de sincronização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Sistema de conta corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.2 2 processos e 1 variável . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Exclusão Mútua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1 Condição de disputa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2 Região Crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.3 Exclusão Mútua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.4 Situações indesejáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Sincronização condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Soluções para a exclusão mútua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1 Soluções por hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1.1 Desligar as interrupções . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1.2 Instruções test-and-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
SUMÁRIO 3
5.6.2 Soluções por software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.6.2.1 Algoritmo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6.2.2 Algoritmo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6.2.3 Algoritmo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6.2.4 Algoritmo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6.2.5 Algoritmo de Dekker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6.2.6 Algoritmo de Peterson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.7 Semáforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.7.1 Exclusão mútua com semáforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.7.2 Sincronização condicional com semáforos . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7.3 Jantar dos filósofos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.8 Monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.9 Troca de mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.10 Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.10.1 Prevenção de deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.10.2 Detecção de deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.10.3 Correção de deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Gerência da UCP 44
6.1 Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.1 Funções básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.2 Partes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.3 Critérios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Tipos de Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.1 Não-preemptivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.1.1 FIFO (First In First Out) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.1.2 SJF (Shortest Job First) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1.3 Cooperativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.2 Preemptivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.2.1 Circular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.2.2 Prioridades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.2.3 Circular com Prioridades . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2.4 Múltiplas filas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2.5 Múltiplas filas com realimentação . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Politicas de Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.1 Tempo Compartilhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.2 Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Capítulo 1
Introdução
1.1 O que é um Sistema Operacional (SO)?

• Programa.
• Conjunto de rotinas.
• Executado de forma não-seqüencial.
1.1.1 Funções:
1. Interação homem-máquina.
2. Gerência de recursos.
3. Administração de usuários da máquina (usuários = programas, pessoas).
1.1.2 Objetivos
1. Compartilhar os recursos de forma organizada e protegida.
2. Facilitar o acesso aos recursos.
OBS: Recursos → UCP, memória, HD ....
1.2 Máquina de Níveis

• Computador → hardware e software como uma coisa só para o usuário.
• 6 níveis:
1. São independentes entre si.
2. A passagem por cada uma é obrigatória.
3. Há uma interface entre as camadas.
4
CAPÍTULO 1. INTRODUÇÃO 5
São eles:
Aplicações
Linguagem de Montagem
Sistema Operacional
Linguagem de máquina
Microprogramação
Hardware (Lógica Digital)
1.3 Tipos de Sistemas Operacionais

Tipos de SO Subtipos
Monotarefa ou Monoprogramável –
Multitarefa ou Multiprogramável Batch, ou em lote; Tempo Compartilhado; Tempo Real
Múltiplas UCPs Sistemas fortemente e fracamente acoplados
• Diferem quanto à:
1. Aplicação
2. Hardware empregado
3. Estrutura interna – complexidade
• Desejável:
1. Escalável
2. Rápido
3. Flexível
4. Seguro
5. Tolerante a Falhas
6. Robusto
1.3.1 Sistemas Monotarefa

• Um único programa em execução.
• Todos os recursos dedicados a esse programa - desperdício
• Estrutura simples
Ex: MS-DOS, PALM OS

1.3.2 Sistemas Multitarefa

• Vários programas em execução.
• Compartilhamento e gerência dos recursos.
• Melhor aproveitamento.
• Estrutura complexa.
• Alguns são multiusuário.
1.3.2.1 Lote ou Batch

• 1º SO multitarefa
• fila de submissão de tarefas
• tarefas não interativas
• Saída em impressora ou disco
• Podem ser eficientes, como também podem ter tempos de resposta longos
• Não são mais usados
1.3.2.2 Tempo Compartilhado (Time-Share)

• Tipo mais comum.
• Conceito de fatia de tempo
• Cada tarefa fica em execução até o tempo acabar, dando lugar a outra
• Tarefas interativas
Ex: UNIX, WINDOWS
1.3.2.3 Tempo Real (Real-Time)

• Semelhante ao sistema time-share, mas não são iguais.
• Tempo de resposta → dentro de intervalos rígidos.
• Conceito de prioridade →tarefa em execução enquanto não houver outro de mais prioridade do que ele
• Prioridade definida pela aplicação.
• Uso em sistemas de missão critica e controle de processos: refinarias, siderúrgicas, trafego aéreo.
1.3.3 Multiplas UCP´s

• Processamento paralelo
• Conceitos:
1. escalabilidade
2. disponibilidade
3. balanceamento de carga
• tendência atual
• Problemas:
1. Necessidade de desempenho
2. Problemas mais caros computacionalmente.
3. ”Lei” de Moore – limite físico.
• Solução:
1. uso de arquiteturas com mais de uma UCP
2. software que tire proveito e escalone entre as UCP´s presentes
• Caracteristicas desejáveis:
1. escalabilidade – alta
2. disponibilidade – alta
3. balanceamento de carga – justo
4. transparência
5. imagem única do sistema
1.3.3.1 Multiprocessadores, ou sistemas fortemente acoplados

• Memória única.
• Tudo gerênciado por um único SO.
• Subdividido em
SMP - Arquitetura simétrica.
NUMA - Acesso Não-Uniforme a Memória.
• Custo de produção mais elevado.

1.3.3.2 Multicomputadores, ou sistemas fracamente acoplados.

• Memória “espalhada”
• Um único SO ou vários
• Cada membro do sistema esta conectado aos outros por um link de dados
• Custo de produção mais baixo.
• Tendência atual
Capítulo 2
Concorrência
2.1 Introdução
• Computador - seu uso é caro computacionalmente
• Objetivo: minimizar o desperdício (tempo que a UCP fica parada)
• Momentos de desperdício:
– Frequência da UCP é maior do que a frequência da memória

– Velocidade da UCP é muito maior do que a velocidade de E/S.
– Baixo uso da UCP em si.
• Solução: Manter a UCP o mais ocupada possível, executando instruções de forma concorrente.
Exemplo: Programa pega 100 registros, ordena e grava o resultado:
Operação Uso Tempo

Ler 100 registros: E/S 0,04 s
Ordenar: UCP 0,01 s
Gravar o resultado: E/S 0,05 s
Total: 0,10 s.
Total de uso da UCP: 0,01
0,10 s = 0, 1 = 10%.
Concorrência - conjunto de técnicas que permite a UCP passar mais tempo ocupada – desempenhando mais
tarefas por instante de tempo (throughput).
Abaixo, algumas técnicas de concorrência.
2.2 Interrupções
• Durante a execução, eventos inesperados podem ocorrer →Desvio forçado na execução - interrupção.
Características:
• Evento assíncrono.
9
CAPÍTULO 2. CONCORRÊNCIA 10
• Evento é externo ao programa.

• Evento gerado por software ou hardware.
• A interrupção é o fundamento básico de concorrência, usado para a sincronização das rotinas do S. O.,
programas, etc.
• Arquitetura IBM-PC: 16 interrupções de hardware, divididas entre 2 controladoras de interrupção (inter-

ligadas em cascata):
Exemplo: IRQ1 - relógio (timer); IRQ3 - porta serial 1; IRQ7 - porta paralela; IRQ13 - IDE 1; etc.
• Há a necessidade de termos mecanismos apropriados para cada tipo de interrupção.
• Como são tratadas:
– Rotina de tratamento de interrupção

– Vetor de interrupção
• Como são assíncronos, podem ocorrer várias vezes, o que atrapalha a execução do programa. Por isso,
temos 2 tipos de interrupções:
– Mascaráveis – podem ser ignoradas.

– Não-mascaráveis – não podem ser ignoradas.
• Controlador de pedidos de interrupção - Hardware que gerencia as interrupções.
2.3 Exceções
• Parecidos com as interrupções, mas diferem nos quesitos:
– Evento interno ao programa.

– Evento síncrono.
– Tratamento é todo via software.
Exemplo: Divisão por zero, buffer overflow, stack overflow, etc.
• Tratamento feito pelo desenvolvedor, ou pelo hardware (em alguns casos).
• Segurança:
– Falhas em programas geram exceções.

– Programação segura.
2.4 Controladoras de E/S

2.4.1 No início...
• UCP fala diretamente com os dispositivos de E/S.
• Problema: E/S é muito mais lento do que a memória ou a UCP.
• Introdução do controlador (ou controladora) de E/S:
– Gerência do acesso aos dispositivos de E/S.

– Tira da UCP o trabalho de cuidar dos dispositivos.
– Mais eficiente do que a UCP fazer o controle.
• Problema ainda existe →a transferência de dados entre a memória e dispositivo de E/S é feita pela UCP.
• ”Interferência” da UCP.
• Abaixo, algumas técnicas empregadas.
2.4.2 E/S Controlada por Programa

• UCP envia a requisição e move os dados entre a memória e a controladora, aguardando o término da
operação.
• UCP fica “presa”, aguardando o término da operação - nada eficiente.
2.4.3 Polling
• UCP envia a requisição, move os dados e é liberada.
• De tempos em tempos, testa para ver se a operação foi concluída.
2.4.4 E/S Controlada por Interrupção

• UCP envia a requisição, move os dados, e é liberada.
• Quando a operação for concluída, a controladora gera uma interrupção, avisando à UCP o término da
operação.
• Muito eficiente, mas ainda requer a interferência direta da UCP, fazendo a transferência de dados.
2.4.5 DMA
• Acesso direto a memória
• Controladora fala direto com a memória, sem passar pela UCP - apenas no início e no fim da transferên-
cia.
• A UCP repassa à controladora a posição inicial da memória a ser lida/escrita, e é liberada.

2.4.5.1 Canal DMA

• Extensão do conceito.
• Diversas “vias” ligando as controladoras da máquina à memória.
• Na arquitetura PC há 8 canais
• Chance de uso de buffers para aumentar ainda mais o desempenho.
2.5 Buffering
• Uso de uma área na memória principal, o buffer.
• Velocidade da UCP é muito maior do que a velocidade de E/S.
• Objetivo: acelerar o acesso aos dispositivos de E/S (leitura e gravação).
• Manter UCP e E/S ocupados na maior parte do tempo.
• Registro como unidade de transferência.
2.6 Spooling
• Fila de submissão de tarefas - inicialmente em fitas magnéticas.
• Arquivo de spool - usado inicialmente em SO´s do tipo batch.
• Fila: 1º a entrar , 1º a sair (FIFO).
• Seqüencial - uso de discos com acesso direto – spooling mais eficiente.
• Não-sequencial - arquivo no disco.
• Uso no gerenciamento de impressão hoje em dia.
2.7 Reentrância
• Mais comum em sistemas multiusuário.
• Vários usuários usando os mesmos programas.
• Problema: Várias cópias do mesmo programa na memória →desperdício.
• Reentrância: capacidade do código-fonte do programa ser executado e compartilhado entre os usuários
do sistema.
• Código executável = código reentrante.
• O código deve ter compilado com essa opção.
• Uso mais eficiente da memória e aumento do desempenho do sistema.
2.8 Proteção do Sistema

• Sistemas mais novos - mais complexos.
• Necessidade de aumentar a segurança
• É preciso garantir a confiabilidade e integridade de programas e dados
• Situações em que mecanismos de proteção são necessários:
1. áreas reservadas para cada programa e seus dados - evitar a sobreposição dessas áreas.
2. comunicação entre programas de forma sincronizada.
3. Compartilhamento de arquivos no disco
4. Evitar “monopólios” da UCP.
5. Contornar exceções.
• O sistema operacional deve evitar esses problemas com mecanismos de controle.

Capítulo 3
Estrutura do sistema operacional
Um sistema operacional é composto de três partes:

1. Kernel.
2. Bibliotecas.
3. Utilitários.
3.1 Kernel
• núcleo do sistema.
• Parte central do sistema operacional.
• oferecem serviços aos usuários.
• execução não-sequencial.
• Principais funções:
1. gerência de processos e threads.

2. gerência de memória.
3. gerência de UCP.
4. gerência de dispositivos de E/S.
5. tratamento de interrupções.
6. tratamento de exceções.
7. suporte a redes.
8. segurança.
9. contabilidade e auditoria do sistema.
• Tipos de kernel: como ele fala com o hardware e software, sua organização interna varia de projeto para
projeto.
• Ideal é que seja pequeno, rápido, estável e seguro.
14
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 15
3.2 Bibliotecas
• Conjunto de rotinas usadas por programas.
• Fornecem serviços para os programas.
• Contém as chamadaa ao sistema.
3.2.1 Chamadas do sistema

• Partes integrantes das bibliotecas.
• Meio organizado e padronizado para acesso ao kernel.
• Forma como o kernel pode ser acessado.
• Esconde a complexidade do acesso para o programador.
• Programa→System Calls→Kernel→Hardware
• Nomes diferentes para a mesma coisa:
1. Windows: API´s
2. Open VMS: System Services
3. UNIX: System Calls
OBS: No Unix, o que determina se um sistema é “padrão UNIX” ou não é se ele segue a especificação das
System Calls, criada pelo comitê POSIX.
3.3 Utilitários
Programas que auxiliam o funcionamento do sistema operacional.
Exemplos: Compiladores, compactadores, ferramentas de acesso ao disco, etc.
3.4 Modos de acesso

• A UCP tem instruções:
1. privilegiadas - tem acesso a todos os recursos, e mal-usadas, podem comprometer o funcionamento

do sistema, gerando instabilidade.
2. não-privilegiadas - não comprometem a estabilidade do sistema operacional.
• Modos de acesso - o que são:
1. Solução implementada em hardware, pela UCP.

2. Acesso ou não à instruções privilegiadas.
3. Informação de qual modo de acesso está salvo em um registrador de estado – PSW.
4. Hoje em dia, os sistemas são montados de forma que o kernel é o único programa que pode estar
sendo executado no modo privilegiado.
• Chaveamento de modos, ou mudança de contexto:
1. Mudança entre os estados do processador, do modo privilegiado para o não-privilegiado, e vice-

versa.
2. Custa (pouco) tempo à UCP, mas é desejável que esse tempo seja ainda mais minimizado.
3.5 Tipos de kernel

Antes, dividiremos entre modo usuário (não-privilegiado) e modo kernel (privilegiado).
3.5.1 Monolítico
• Um grande bloco de código, ou dividido em módulos, todos sendo executados no modo kernel.
• Estrutura mais simples.
• Desenvolvimento mais simples.
• A manutenção pode ser complexa, se não for um projeto bem-feito e bem amarrado.
• Simples na estrutura.
• Rápido.
Ex: MS-DOS, Linux.
3.5.2 Camadas
• Níveis sobrepostos.
• Há necessidade de passar por todos os níveis para chegar ao kernel.
• Como as camadas são isoladas, facilita a manutenção e a depuração.
• Desempenho prejudicado pela estrutura - muito burocrático.
Ex: Open VMS, MULTICS, Windows 2000
3.5.3 Máquina Virtual

• Sistema computacional composto por níveis, onde o nível mais baixo é o hardware.
• Modelo de máquina virtual - nível intermediário entre o hardware e o sistema operacional - gerência de
máquinas virtuais.
• Cada máquina virtual oferece uma cópia virtual do hardware, incluindo os modos de acesso, interrupções,
dispositivos de E/S, etc.
• Cada máquina virtual é independente das demais, contendo seu próprio sistema operacional, seus pró-
prios usuários e suas próprias aplicações.
• Conceito iniciado no VM/370, baseado no OS/370, da IBM (anos 1960).
• Conceito usado também com a linguagem Java - JVM.
• Vantagens:
1. Segurança - Isolamento total das máquinas virtuais.

2. Economia de recursos - mais barato um servidor grande do que vários servidores pequenos.
3. Portabilidade - se o hardware hospedeiro tiver um defeito, basta transferir os arquivos das máquinas
virtuais para outro hardware.
• Desvantagens:
1. Complexidade.
2. Sobrecarga - um hipervisor é complexo e consome muitos recursos do hardware hospedeiro.
3.5.4 Microkernel
• Constatação - sistemas atuais ainda são lentos e pesados.
• Microkernel - tornar o núcleo do sistema operacional o menor e mais simples possível.
• Disponibilizar os serviços através de processos a serem executados no nível usuário.
• Cada um desses processos servidores fornecem um recurso específico para o sistema: Gerência de pro-
cessos, gerência de arquivos, escalonamento de processos, etc.
• A principal função do kernel então é fazer o diálogo entre os diferentes processos servidores.
• Conceito surgido nos anos 1980, com o sistema operacional Mach, desenvolvido na Universidade Carnegie-
Mellon.
• O núcleo do Mach fornece 4 serviços, apenas: Gerência de processos, gerência de memória, comunicação
por troca de mensagens e operações de E/S, todas em modo usuário.
• Vantagens:
1. Mais seguro: Se um serviço sair do ar, é recolocado facilmente.

2. Apropriado para computação distribuída: Os serviços podem ser remanejados entre as UCPs.
3. Mais flexível.
4. Mais rápido: com o kernel enxuto, menos código a ser executado.
5. Mais facilmente portado para outras arquiteturas: Menos código no kernel, menos dificuldades para
reescrever o kernel para outras plataformas.
• Há controvérsias quanto à afirmação de ser mais rápido (ponto no. 4), pois apesar do kernel ser menor, o
sistema fará muito mais chamadas e mudanças de modo de acesso, ao acessar os serviços que rodam no
modo usuário.
• Na prática, os sistemas microkernel são interessantes, mas ainda não podem estar disponíveis comercial-
mente. Existem alguns sistemas que agregam características do microkernel, mas não são completamente
nesse estado.
Exemplos: L4, Amoeba, Exokernel, Minix.

Capítulo 4
Processos e threads
4.1 Introdução
• Conceito - base para a implementação de um sistema multiprogramável.
• Um programa deve estar sempre associado a um processo.
• Processo - ambiente no qual um programa é executado.
• O processo é colocado em execução e é tirado caso o sistema operacional necessite fazê-lo.
4.2 Partes do processo

• Três partes:
1. Espaço de endereçamento: Área de memória usada pelo processo, onde as instruções e os dados do
programa são armaenados para execução.
2. Contexto de hardware: Registradores gerais e específicos da UCP. Quando um processo está em
execução, o contexto de hardware guarda os registradores do processador. Quando ele é tirado de
execução (mudança de contexto), todos os registradores são salvos no contexto de hardware, para
que o processo seja novamente colocado em execução, a partir do ponto onde parou.
3. Contexto de software: Características e limites dos recursos que podem ser alocados pelo processo.
Muitas dessas características são determinadas no momento da criação do processo, enquanto outras
podem ser alteradas durante a sua existência. São três grupos de informações:
– Identificação:
* Número de identificação do processo (PID).
* Nome do usuário que criou o processo (UID).
* Grupo do usuário que criou o processo (GID).
– Quotas: Limites de cada recurso do sistema que um prcoesso pode alocar. Exemplos:
* Número máximo de arquivos abertos simultaneamente;
* Número máximo de operações de E/S pendentes;
* Tamanho máximo do buffer para operações de E/S;
19
CAPÍTULO 4. PROCESSOS E THREADS 20
* Número máximo de processos, subprocessos e threads que podem ser criados.

– Privilégios: Ações que um processo pode fazer em relação a ele mesmo, aos demais processos e ao
sistema operacional. Exemplos:
* Alterar a prioridade de execução;
* Limites alocados na memória principal e secundária;
* Alterar as prioridades de outros processos;
* Desativar o sistema;
* Alterar regras de segurança;
* Criar outros processos privilegiados;
* Mudar a configuração do sistema.
4.3 Bloco de controle do processo (PCB)

• O bloco de controle do processo é uma estrutura de dados, mantida pelo sistema operacional, em área
reservada, onde todas as informações necessárias para manter o processo em funcionamento são arqui-
vadas.
• A gerência de processos é feita por chamadas do sistema.
4.4 Estados do processo e mudanças de estado

• Três estados:
1. Execução: Sendo executado pela UCP.

2. Prontidão (ou pronto): Aguarda a sua vez para ser executado.
3. Espera: Aguarda pelo fim de um evento externo ou por um recurso para continuar o processamento.
Escalonamento: Conjunto de critérios que definem qual processo será colocado em execução primeiro.
4.4.1 Mudanças de estado

• Eventos voluntários ou involuntários podem mudar o estado de um processo:
1. Eventos voluntários: O processo muda por causa de eventos originários de si mesmo.

2. Eventos involuntários: O processos muda por ação do sistema operacional.
• Mudanças:
1. Pronto → execução: Colocado em execução.

2. Execução → espera: Evento externo, como uma operação de E/S, faz o processo ter seu estado
mudado.
3. Espera → pronto: O evento externo foi concluído. Note que não há como passar direto, de espera
para execução.
4. Execução → pronto: O término da fatia de tempo que o processo tem o coloca de volta na fila de
prontidão.
• Processos no estado de espera ou pronto podem estar na memória virtual, por falta de espaço. Logo, a
técnica de swapping consiste em mover processos entre as memórias principal e virtual.
4.5 Criação e eliminação de processos

• Dois estados adicionais:
1. Criação → Criou-se a entrada no PCB, mas o processo ainda não foi colocado na lista de prontidão.
É criado por outros processos.
2. Término → O programa foi finalizado, mas o PCB ainda existe. É eliminado por outros processos
ou pelo término nortmal da sua execução.
4.6 Concorrência dentro de uma aplicação

• Três maneiras:
1. Processos independentes: Um processo cria outros, sem vínculos. É a maneira mais simples.
2. Subprocessos: Um processo cria outros, de forma que estão vinculados hierarquicamente: Se o
processo-pai é eliminado, os processos-filho também serão. Compartilham quotas.
3. Threads: Ramificações dentro do processo, compartilhando o contexto de software e o espaço de
endereçamento. É um modo de gastar menos tempo com criação, escalonamento e eliminação de
processos.
4.7 Tipos de processo

1. Foreground: Execução em primeiro plano, interage diretamente com o usuário, com entrada-padrão
(teclado) e saída-padrão (monitor).
2. Background: Execução em segundo plano, onde não é preciso interagir diretamente com o usuário. Nesse
caso, entrada e saída podem ser arquivos, por exemplo.
3. CPU-Bound: Passa a maior parte da fatia de tempo em estado de execução, ou seja, usando a UCP
intensamente.
4. I/O-Bound: Passa a maior parte da fatia de tempo em estado de espera, com muitas operações de E/S.
4.8 Sinais
• Mecanismo que permite ”avisar” processos de eventos gerados pelo sistema operacional ou por outros
processos.
• Também são usados para comunicação e sincronização entre processos.

• Podem ser associados a temporizadores (eventos associados ao tempo).
Exemplos: Notificação de interrupções e exceções, alarmes de tempo, limites de quotas excedidos, etc.
• Eventos que geram sinais - síncronos ou assíncronos.
• Tratamento do sinal - semelhante ao mecanismo de interupções.
• O sinal está para o processo assim como interrupções e exceções estão para o sistema operacional.
4.9 Threads
4.9.1 Introdução
• No início, eram apenas processos.
• Conceito de processo ”leve” (lightweight) → compartilha o espaço de endereçamento.
• Thread - surge primeiro no sistema operacional Mach, da Universidade de Carnegie-Mellon (1980).
• Ganho de desempenho e flexibilidade, apesar da complexa implementação.
• Aplicações mais complexas - vários trechos de código em execução paralela - para termos comunicação
e sincronização de threads deve-se avaliar desempenho, flexibilidade e custo.
• Apesar da dificuldade em desenvolver, compensa devido aos ganhos obtidos.
Exemplos: Windows 2000 e superiores, Linux, Solaris, etc.
4.9.2 Ambientes monothread e multithread

4.9.2.1 Monothread
• Cada processo tem apenas um thread.
• Concorrência se dá apenas com processos independentes ou subprocessos.
• Problema - criar, gerenciar e eliminar processos é computacionalmente caro.
• Compartilhar o espaço de endereçamento é complexo, por conta dos mecanismos empregados.
• Processo →Unidade de alocação e de escalonamento.

4.9.2.2 Multithread
• Permite que tenhamos aplicações concorrentes de forma mais eficiente:
– Aumenta o desempenho, por dispensar mecanismos de comunicação dentrod o processo.

– Aumenta a eficiência, por termos menos sobrecarga do sistema como um tyodo - menos processos
e mais threads.
• Programas associados a threads.

• Os threads sofrem mudança de estado (pronto, espera e execução), e tem seu próprio bloco de controle
(o TCB).
• Processo →Unidade de alocação.
• Thread →Unidade de escalonamento.
• O S. O. vê e escalona os threads de cada processo.
4.9.3 Formas de implementação

• Pacote de threads - Conjunto de rotinas da biblioteca do sistema operacional par aa implementação de
threads.
• Falta de padrão em sistemas Unix, até o comitê POSIX liberar uma norma para termos threads, os PTh-
reads.
4.9.3.1 Threads em Modo Usuário (TMU)

• Implementados pela aplicação.
• O sistema operacional não vê os threads, apenas o proceso como um todo.
• Podemos ter aplicações multithread em ambientes monothread.
• São rápidos e eficientes, por não fazerem acessos ao kernel, e as mudanças de modo de acesso da UCP
(usuário-kernel-usuário).
• Uma chamada a um dispositivo de E/S, feita por um thread, coloca todo o processo em estado de espera.
• O tratamento dos sinais também é complexo, pois o processo terá que tratar o sinal e direcioná-lo ao
thread certo.
4.9.3.2 Threads em Modo Kernel (TMK)

• Implementados pelo kernel.
• O sistema operacional gerencia diretamente os threads de um processo.
• Requer mudanças de modo de acesso, logo tem desempenho degradado - bem mais lentos.
• Chamadas bloqueantes colocam apenas o thread em estado de espera, não todo o processo.
• Podemos ter vários threads de um mesmo processo em execução simultânea, em UCPs diferentes.
4.9.3.3 Threads em Modo Híbrido (TMH)

• Combina as vantagens dos threads em modo usuário (TMU) e em modo kernel (TMK), mas também as
desvantagens.
• Um processo tem vários TMKs, e cada TMK tem vários TMUs.
• O sistema operacional escalona os TMKs, e eles escalonam os TMUs.
• O objetivo é aumentar a flexibilidade, já que apenas os TMKs são escalonados (diminuindo o número de
mudanças de modo de acesso), mas também traz os problemas das chamadas bloqueantes, entre outras.
4.9.3.4 Scheduler activations

• Os Threads em Modo Híbrido (TMH) tem problemas devido à falta de comunicação entre os threads.
• É desejável unir o melhor das implementações, fugindo dos problemas de cada uma.
• O scheduler activations foi implementado inicialmente na Universidade de Washington, e nessa forma,

há uma estrutura de dados que facilita a troca de informações entre o kernel e a biblioteca de threads.
Essa estrutura é o scheduler activations.
• O escalonamento é feito pela própria biblioteca, evitando as mudanças de modo de acesso, como por
exemplo a ocorrência de uma chamada bloqueante.
• Ambas as partes se comunicam, e trabalham cooperativamente.

Capítulo 5
Sincronização entre processos
5.1 Introdução
• Anos 1960: sistemas operacionais multitarefa →surgem as primeiras aplicações que podem funcionar
de maneira concorrente, ou seja: diferentes partes do código do programa podem funcionar simultanea-
mente.
– Uso de subprocessos ou threads.

– Escalonamento organizado pelo SO.
– Objetivo: Aumentar o desempenho.
• Esses processos que compõem a aplicação concorrente precisam compartilhar recursos:
Exemplos: Arquivos, registros, dispositivos de E/S, regiões de memória.
• Podem ocorrer situações indesejáveis, que podem até comprometer a execução da aplicação.
• Importante garantir a integridade e a confiabilidade.
• Necessidade das execuções serem sincronizadas, a partir de mecanismos fornecidos pelo sistema opera-
cional, para garantir o processamento correto
• A comunicação entre processos pode ser estabelecida usando mecanismos. É necessário que os proces-
sos estejam com sua execução sincronizada
Exemplos: (mecanismos de comunicação) Variáveis compartilhadas da memória principal ou trocas de

mensagens.
5.2 Concorrência no código fonte:

5.2.1 Comandos FORK e JOIN
5.2.1.1 Como funciona
• FORK cria um subprocesso B a partir do processo A.
25
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 26
Figura 5.1: Sincronização entre processos.
• Eles são concorrentes.
• JOIN sincroniza A com B → A p´ara e espera o fim da execução de B.
5.2.2 ParBegin e ParEnd (CoBegin e CoEnd)

5.2.2.1 Como funciona
• Implementado de formas diferentes em várias linguagens de programação.
• Ao invés de usar BEGIN e END como delimitadores de bloco, usa-se PARBEGIN e PAREND.
– Todos os comandos que estiverem no bloco serão executados de forma concorrente.

* PARBEGIN: Ramifica o código, criando 1 processo para cada comando.
* PAREND: Cria um ponto de sincronização, reunindo todos os processos e seus resultados num
processo principal.
5.3 Exemplos de problemas de sincronização

5.3.1 Sistema de conta corrente
• Atualização do saldo, realizando entradas e saídas.
• 2 processos fazem lançamentos na concta corrente de um cliente.
– Um faz débitos, e outro realiza créditos:
• Suponhamos então, 2 processos (Caixa 1 e Caixa 2) realizando operações na conta desse cliente.
Figura 5.2: PARBEGIN e PAREND.
Algorithm 5.1 Programa de Conta Corrente.

Programa Conta Corrente;
.
.
Leia (arquivo de contas, registro do cliente);
Leia (valor a ser depositado ou retirado);
Registro do cliente.Saldo ←Registro do cliente.Saldo + valor a ser depositado ou retirado;
Grava (arquivo de contas, registro do cliente);
.
.
.
Caixa Comando Saldo no arquivo Valor Saldo na memória

1 Leia (arquivo de contas, ...) 1000 - 1000
1 Leia (valor a ser depositado ou retirado) 1000 -200 1000
1 Registro do cliente.Saldo 1000 -200 800
2 Leia (arquivo de contas, ...) 1000 - 1000
2 Leia (valor a ser depositado ou retirado) 1000 +300 1000
2 Registro do cliente.Saldo 1000 +300 1300
1 Grava (arquivo de contas, ...) 1000 -200 800
2 Grava (arquivo de contas, ...) 1000 +300 1300
Logo, temos uma incoerência, já que um caixa quer salvar o valor de 1300, e o outro quer salvar o valor de
800. Qual deles está certo?
5.3.2 2 processos e 1 variável

• Processo A: Incrementa uma variável.
• Processo B: Decrementa uma variável.
Algorithm 5.2 Exemplos de código.

Processo A:
• Coloca X em Ra.
• Soma 1 a Ra.
• Salva Ra em X.
Processo B:
• Coloca X em Rb.
• Subtrai 1 a Rb.
• Salva Rb em X.
Processo Comando X Ra Rb
A Carrega 2 2 -
A Soma 2 3 -
B Carrega 2 - 2
B Subtrai 2 - 1
A Salva 3 3 -
B Salva 3 - 1
Mais uma incoerência, pois X não poderá ter 2 valores, 3 e 1.
5.4 Exclusão Mútua

5.4.1 Condição de disputa
• O problema de inconsistência nos dados, devido à falta de sincronização.
5.4.2 Região Crítica

• A parte do código-fonte onde é feito o acesso aos recursos compartilhados.
• Objetivo: Obter a exclusão mútua.
• Logo, só um programa pode acessar a sua região crítica por vez.

5.4.3 Exclusão Mútua

• A solução mais simples para evitar os problemas de compartilhamento é impedir que 2 ou mais processos
acessem um mesmo recurso simultaneamente.
• Enquanto um processo estiver acessando determinado recurso, todos os demais processos que queiram
acessá-lo deverão esperar pelo término da utilização do recurso.
• Acesso de forma ordenada, organizada e individual ao recurso.
• Exclusividade de acesso.
Exemplo: No problema do banco (subseção 5.3.1), basta garantir que o acesso à conta (a região crítica do
código) seja exclusivo: um espera equanto o outro acessa.
5.4.4 Situações indesejáveis

1. Starvation
• Também conhecida como espera indefinida.

• Um dos processos nunca sai da sua região crítica, e o outro "passa fome".
• Pode ocorrer em escalonamentos onde a escolha é aleatória ou com base em prioridades.
• Uma solução é usar filas de pedidos de alocação para cada recurso, e cada uma dessas filas usando
o escalonamento em fila (FIFO).
2. Espera ocupada;
• Toda vez que um processo não consegue entrar na sua região crítica, ele permanece repetidamente
testando uma condição, tentando acessar o recurso.
• Isso continua até o processo ”persistente” conseguir o acesso.
• Problema: Isso consome tempo do processador de forma desnecessária.
3. Um processo sai da região crítica e não deixa que outros entrem.
• Recurso livre, mas ainda ligado a um processo.
5.5 Sincronização condicional

• Situação onde o acesso ao recurso compartilhado exige a sincronização de processos vinculada a uma
condição de acesso.
• Essa condição é bloqueante para os processos.
Exemplo: Modelo produtor-consumidor:
• O recurso compartilhado é um buffer de espaço limitado.
• Dois ou mais processos acessam o recurso:

– Produtores - gravam no buffer

– Consumidores - leem o buffer
• Condições:
– Buffer vazio - consumidor espera

– Buffer cheio - produtor espera
Algorithm 5.3 Modelo produtor-consumidor.

Programa PA1;
Constante
Tamanho do buffer = X;
Variáveis
Buffer: vetor de dado (1 a X);
D1, D2: dado;
Conta: 0..X;
Procedimento Produtor;
Início
Repita
Produz Dado (D1);
Enquanto conta for igual a X não faça nada;
Grava o buffer (Buffer, D1);
Incrementa Conta;
Até que seja falso;
Fim;
Procedimento Consumidor;
Início
Repita
Enquanto conta for igual a 0 não faça nada;
Lê o buffer (Buffer, D2);
Consome Dado (D2);
Decrementa Conta;
Fim;
Início
Conta ←0;
Início (em paralelo)
Produtor;
Consumidor;
Fim (em paralelo);
Fim.
Nesse caso, teremos a espera ocupada.

5.6 Soluções para a exclusão mútua

5.6.1 Soluções por hardware
5.6.1.1 Desligar as interrupções
Algorithm 5.4 Desligamento das interrupções do sistema.

Início
.
.
.
Desliga as interrupções do sistema;
Entra na Região Crítica;
Sai da Região Crítica;
Liga as interrupções do sistema;
.
.
.
Fim;
• Dessa forma nenhum outro programa interrompe o primeiro.
• Maneira simples.
• Atrapalha a multiprogramação.
• Se o programa não religar as interrupções, trava tudo.
– Clock usa interrupções.
• Múltiplas UCPs - Essa informação (de desligamento e religamento) deve propagar para todas as UCPs.
• Usado às vezes com partes do kernel.
5.6.1.2 Instruções test-and-set

• Instrução especial da UCP.
– Lê a variavel.
– Salva seu conteódo em outra área da memória.
– Grava um novo valor na mesma variável.
• Dessa forma, 1 variável compartilhada pode ser manipulada por 2 processos simultaneamente.
• Uso:
– Usa-se uma variavel booleana.

* Falso = Qualquer processo pode acessar

* Verdadeiro = Processo acessando o recurso.
• Manuseio simples
• Funciona bem com múltiplas UCP .
• Depende dessa instrução existir na UCP.
• Possibilidade de starvation.
5.6.2 Soluções por software

• Diversos algoritimos foram pensados ao longo do tempo.
• Uso de uma variável de bloqueio.
– Testa se a região crítica está liberada ao ler essa variável.
5.6.2.1 Algoritmo 1
Algorithm 5.5 Algoritmo 1 para exclusão mútua.

Programa Algoritmo 1;
Variável
Vez: caracter;
Procedimento A;
Início
Repita
Enquanto Vez for igual a B não faça nada;
Entre na Região Crítica do procedimento A;
Vez ←B;
Realize o processamento do procedimento A;
Fim;
Procedimento B;
Início
Repita
Enquanto Vez for igual a A não faça nada;
Entre na Região Crítica do procedimento B;
Vez ←A;
Realize o processamento do procedimento B;
Fim;
Procedimento A;
Procedimento B;
Fim (em paralelo).
• Só funciona com dois processos.
• Acesso alternado.
• Se não alterar a variável de bloqueio, o recurso fica sempre inacessível, que gera starvation.
5.6.2.2 Algoritmo 2

Variáveis
CA, CB: Booleano;
Procedimento A;
Início
Repita
Enquanto CB for Verdadeiro não faça nada;
CA ←Verdadeiro;
CA ←Falso;
Fim;
Procedimento B;
Início
Repita
Enquanto CA for Verdadeiro não faça nada;
CB ←Verdadeiro;
CB ←Falso;
Fim;
Início
CA←Falso;
CB←Falso;
Procedimento A;
Procedimento B;
Fim (em paralelo).
Fim.
• Substituição da variável de bloqueio por duas variáveis, uma para cada processo.
• Não há necessidade de acessar alternadamente.
• Se houver um problema, o recurso não fica bloqueado, a não ser que a falha seja dentro da região crítica.
5.6.2.3 Algoritmo 3

Variáveis
CA, CB: Booleano;
Procedimento A;
Início
Repita
CA←Verdadeiro;
CA ←Falso;
Fim;
Procedimento B;
Início
Repita
CB ←Verdadeiro;
CB ←Falso;
Fim;
Início
CA←Falso;
CB←Falso;
Procedimento A;
Procedimento B;
Fim (em paralelo).
Fim.
• O problema do algoritmo anterior consiste em o processo ter algum problema quando está na sua região
crítica, e com isso o acesso ao recurso fica travado.
• Uma maneira de resolver o problema do algoritmo anterior é mudar as variáveis CA e CB antes de testar
se o recurso está disponível.
• Só que temos um novo problema: ambos os processos podem ficar bloqueados. Se ambos mudarem os
valores das variáveis CA e CB, ninguém entra na sua região crítica e ninguém usa o recurso.
5.6.2.4 Algoritmo 4
• O processo entra na região crítica sem saber se o outro está acessando o recurso.

Variáveis
CA, CB: Booleano;
Procedimento A;
Início
Repita
CA←Verdadeiro;
Início
CA←Falso;
{ pequeno intervalo de tempo }
CA←Verdadeiro;
Fim;
CA ←Falso;
Fim;
Procedimento B;
Início
Repita
CB←Verdadeiro;
Início
CB←Falso;
{ pequeno intervalo de tempo }
CB←Verdadeiro;
Fim;
CB ←Falso;
Fim;
Início
CA←Falso;
CB←Falso;
Procedimento A;
Procedimento B;
Fim (em paralelo).
Fim.
• Uma maneira de evitar o bloqueio de ambos é dando a chance de reverter o processo, e alterar novamente
o valor das variáveis CA e CB.
• Pode acontecer que ambos os processos alterem seu estado (variável que marca a entrada na região
critica) para falso, simultaneamente. Ou seja, teremos bloqueio para ambos.
5.6.2.5 Algoritmo de Dekker

• A primeira solução completa para o problema da exclusão mútua.
• Baseada nos algoritmos 5.5 e 5.8 para obter a exclusão mútua entre 2 processos.
• Lógica bastante complexa.
5.6.2.6 Algoritmo de Peterson

• Solução baseada no algoritmo de Dekker.
• Facilmente generalizado para n processos.
• Parecido com o algoritmo 5.7.
• Como funciona:
– Cada processo tem uma variável de estado que sinaliza o desejo de entrar na região crítica.
– Uma variável é usada para arbitrar conflitos: a variável cede o uso para outro processo.
• O algoritmo de Dekker e a versão inicial do algoritmo de Peterson garantem a exclusão mútua de 2

processos.
• O algoritmo de Peterson foi estendido para o caso de N processos por Hofri (1990).
• Lamport propôs um algoritmo para garantir a exclusão mútua, que é o algoritmo do padeiro.
• Todos ainda sofrem de espera ocupada (seção 2).
• Uma maneira de resolver é usando semáforos (ou monitores) como mecanismos de sincronização.
5.7 Semáforos
• Ideia simples para sincronização.
• Conceito proposto pro Dijkstra em 1965
• Semáforo:
– Variável inteira e não negativa.
– São vinculados ao recurso compartilhado.
– Só pode ser manipulada por 2 instruções.
1. UP - incremento.
2. DOWN - decremento.
• 2 tipos:
– binários, ou mutexes (mutual exclusion semaphores): 2 estados.
– contadores: n estados.
Algorithm 5.9 Algoritmo de Peterson para exclusão mútua.

Programa Algoritmo Peterson;
Variáveis
CA, CB: Booleano;
Vez: Caractere;
Procedimento A;
Início
Repita
CA←Verdadeiro;
Vez ← ”B”;
Enquanto CB for Verdadeiro e Vez for igual a ”B”, não faça nada;
CA ←Falso;
Fim;
Procedimento B;
Início
Repita
CB ←Verdadeiro;
Vez ←”A”;
Enquanto CA for Verdadeiro e Vez for igual a ”A”, não faça nada;
CB ←Falso;
Fim;
Início
CA←Falso;
CB←Falso;
Procedimento A;
Procedimento B;
Fim (em paralelo).
Fim.
5.7.1 Exclusão mútua com semáforos

• Semáforo ligado ao recurso compartilhado:
– Semáforo está com 1, sofre um DOWN, e muda para o estado 0. →o processo entra na região
crítica.
– Semáforo está com 0, sofre um DOWN (não temos o estado -1) →o processo é mantido em estado
de espera.
– Semáforo está com 0, sofre um UP, e muda para o estado 1 →o processo sai da região crítica.
Algorithm 5.10 Código fonte comum para exemplos com semáforos.

tipo semaforo = registro
valor = inteiro
fila de espera {lista de processos em espera}
fim;
Procedimento DOWN (s: inteiro);
Início
Se s=0 então coloca o processo na fila de espera;
s–;
Fim;
Procedimento UP (s:inteiro);
Início
s++;
Se tem processo esperando, então coloca em execução;
Fim;
Algorithm 5.11 Exclusão mútua usando semáforos.

Programa Semáforo 1;
Variável A: Semáforo ←1;
Procedimento processo A;
Início
Repita
DOWN(s);
Entra na região crítica de A;
UP(s);
até que seja falso;
Fim;
Procedimento processo B;
Início
Repita
DOWN(s);
Entra na região crítica de B;
UP(s);
Fim;
Procedimento A;
Procedimento A;
Fim (em paralelo);
5.7.2 Sincronização condicional com semáforos

• Podemos usar semáforos para lidar com a sincronização condicional.
– Quando um processo solicita uma operação de E/S, ele executa um DOWN no semáforo associado
ao recurso, e é colocado em estado de espera até que a operação seja completada.
– Quando a operação termina, a rotina de tratamento da interrupção executa um UP no semáforo,
liberando o processo do estado de espera.
5.7.3 Jantar dos filósofos

• Problema:
– 5 filósofos, que são os processos.

– 5 pratos, que são as regiões críticas.
– 5 garfos, que são os recursos compartilhados.
• Limitações:
1. O filósofo ou pensa (estado de espera), ou come (entra na região crítica).

2. Para comer, o filósofo precisa de 2 garfos.
• Deadlock
– Ocorre se cada um dos filósofos pegar um garfo.
• Algumas soluções
1. O número de filósofos à mesa é menor do que o número de garfos (neste caso, no máximo 4).
2. Um filósofo só pode pegar um garfo se o outro estiver disponível.
3. O filósofo ímpar pega o garfo da direita e depois da esquerda, e o filósofo par pega o grafo da
esquerda e depois da direita.
• Ainda temos o risco de um deadlock. Para evitar, podemos acrescentar um novo semáforo contador,
para marcar os lugares começando em 4 (menor do que número de talheres), e dessa forma garantir que
teremos sempre mais talhetes do que filósofos à mesa. e fazendo down e up tambem. Dessa forma,
teremos sempre mais talheres do que filósofos a mesa.
Algorithm 5.12 Algoritmo de sincronização condicional usando semáforos.

Programa Semaforo2;
Constante
Tamanho do buffer = 2;
Tipo
Tipo de dado = {um tipo qualquer};
Variáveis
Vazio: semáforo = Tamanho do buffer;
Cheio, evento: semáforo = 0;
Mutex: semáforo = 1;
Buffer = vetor de tipo de dado (1 a Tamanho do buffer);
Dado 1, Dado 2: Tipo de dado;
Início
Repita
Produz Dado (Dado 1);
Down (Vazio);
Down (Mutex);
Grava no buffer (Dado 1, Buffer);
Up (Mutex);
Up (Cheio);
Fim;
Procedimento Consumidor;
Início
Repita
Down (Cheio);
Down (Mutex);
Lê o buffer (Dado 2, Buffer);
Up (Mutex);
Up (Vazio);
Consome Dado (Dado 2);
Fim;
Produtor;
Consumidor;
Fim (em paralelo).
5.8 Monitores
• Mecanismos de sincronização semelhantes aos semáforos, mas de alto nível e estruturados.
– Por quê? Os semáforos são não-estruturados, e qualquer engano por parte do programador pode
levar a problemas de sincronização.
• Os monitores são hoje em dia estruturas criadas dentro dos programas, que agregam procedimentos e
Algorithm 5.13 Jantar dos filósofos.

Programa filósofo 1;
Variáveis
Garfos: vetor(1 a 4) de semaforo =1;
i: inteiro;
Procedimento filósofo (i:inteiro);
Início
repita
pensando;
down(garfos(i));
down(garfos((i+1) mod 5));
comendo;
up(garfos(i);
up(garfos(i+1) mod 5));
Fim;
Para i←de 1 ate 5 faça
filósofo(i)
Fim (em paralelo).
variáveis, e quem garante a exclusão mútua é o compilador: O programa não tem acesso às variáveis que
seriam os semáforos, no caso do monitor.
• As variáveis globais, definidas dentro dos monitores, só são visíveis dentro dessas estruturas.
• Os procedimentos criados dentro dos monitores só são acessíveis através dos mesmos.
• O programa verifica com o S. O. se existe outro processo, gerando uma possível condição de disputa. Se
existe, o programa aguarda a sua vez, ficando numa fila de espera. Se não existe, o programa entra na
sua região crítica.
• Várias linguagens já tem estruturas implementadas para lidar com monitores, como Modula-2, Modula-3,
Concurrent Pascal, etc.
5.9 Troca de mensagens

• Mecanismo de comunicação e sincronização entre processos.
• O uso desse mecanismo dispensa o uso de variáveis compartilhadas, mas exige um canal de comunicação,
que pode ser um buffer ou um link de dados.
• As execuções entre os rpocessos comunicantes devem estsr sincronizadas, para manter a relação causa-
efeito da comunicação (a mensagem deve chegar ao destino com um tempo maior do que saiu).
• Dois tipos:
1. Comunicação direta
– Mensagem endereçada diretamente ao receptor.

– Só há a troca de mensagens, apenas.
– É preciso declarar claramente quem envia e quem recebe. Se mudar, tem que mudar dentro do
código.
2. Comunicação indireta
– Uso de uma área compartilhada que faz o papel de "caixa de correio" (mailbox, ou port).
– Essa área compartilhada pode ser associada a vários processos.
– Os procedimentos passam a endereçar a área compartilhada, e não os processos. Logo, caso
mude o processo, não é preciso fazer alterações no código.
5.10 Deadlock
• Processo aguarda um recurso que nunca virá, ou um evento que nunca ocorrerá.
• Devido a isso, ele não libera o recurso que está sob seu uso, e outros processos acabam tendo o mesmo
problema, gerando uma reação em cadeia que cria o que chamamos de espera circular:
1. O Processo A retém o recurso 1 e pede o recurso 2, que está com o Processo B.

2. O Processo B retém o recurso 2 e pede o recurso 3, que está com o Processo C.
3. O Processo C retém o recurso 3 e pede o recurso 3, que está com o Processo A.
• Quatro condições para termos um deadlock:
1. Exclusão mútua - O processo está associado a um recurso.

2. Espera por recurso - Processo no aguardo.
3. Não-preempção - Recurso não pode ser liberado para outros processos fazerem uso.
4. Espera circular - Processo aguarda por um recurso que está associado a outro processo, e por aí vai.
5.10.1 Prevenção de deadlocks

Objetivo: Garantir que uma das quatro condições acima não aconteça:
1. Se tirarmos a condição 1, gera inconsistências.
2. Se tirarmos a condição 2, quem tem recursos, tem que liberar para poder pegar novos recursos.
(a) Desperdício, na utilização dos recursos.

(b) Não dá para alocar previamente tudo o que o processo vai usar.
3. Se tirarmos a condição 3, então permitiremos que um recurso seja tirado de um processo caso outro
processo também precise do recurso. Só que isto pode gerar problemas, como por exemplo o processo
ter a sua execução interrompida. Também poderemos ter starvation.
4. Se tirarmos a condição 4, cada processo só pode alocar um recurso de cada vez, e para alocar um novo,
é preciso liberar o primeiro. Isto restringe severamente o compartilhamento de programas.
• Logo, prevenir o deadlock é possível, mas todas as soluções apresentadas não são nada práticas, e con-
sequentemente, não são usadas.
• A maneira mais adotada é usar o algoritmo do Banqueiro (Dikjstra, 1965), onde cada processo informa
ao sistema operacional qual recurso está usando, qual é o estado, entre outras informações. Assim, o
algorimo define qual é o estado de alocação de um recurso, e com base nisso, previne possíveis deadlocks.
5.10.2 Detecção de deadlocks

Os sistemas operacionais mantém estruturaa de dados capazes de armazenar informações do sistema, e iden-
tificar cada recurso do sistema, quem os está alocando, entre outras infromações. A estrutura é atualizada
com recursos alocados ou liberados, e observando-a, o sistema pode detectar a espera circular que porventura
ocorra.
5.10.3 Correção de deadlocks

• Depois da detecção, a correção.
• Quebra da espera circular.
– Elimina-se processos para liberar recursos.

– Só que isto pode gerar instabilidades no sistema - Qual processo deve ser eliminado?
• Rollback - Liberar alguns recursos temporariamente, para depois realocá-los aos processos congelados,
continuando de onde parou. Na prática é difícil, pois depende do processos a ser congelado, se dá para
pará-lo, por exemplo.
Capítulo 6
Gerência da UCP
6.1 Escalonamento
• Processo de seleção de um processo a ser executado, e o conjunto de critérios que definem a fila de
execução do sistema operacional.
6.1.1 Funções básicas

• Manter a UCP o máximo ocupada.
• Balancear o uso da UCP entre os processos.
• Maximizar o throughput.
• Dar tempos de resposta razoáveis.
6.1.2 Partes
• escalonador (scheduler) – decide.
• dispatcher – executa.
6.1.3 Critérios
• uso da UCP – em porcentagem.
• throughput – nº de processos / tempo.
• tempo de UCP.
• tempo de espera.
• tempo de turnaround.
• tempo de resposta.
44
CAPÍTULO 6. GERÊNCIA DA UCP 45
6.1.4 Objetivos
• Maximizar uso e throughput.
• Minimizar tempos.
6.2 Tipos de Escalonamento

6.2.1 Não-preemptivos
• O processo é executado enquanto quiser
6.2.1.1 FIFO (First In First Out)

• O 1º a entrar na fila é o 1º a ser executado.
• Foi usado em sistemas batch.
• Simples, mas não dá para prever quando o processo termina ou vai para estado de espera.
Exemplo: Temos 3 processos a serem executados, com seus respectivos tempos de processador e ordem de
execução:
Processo Tempo de UCP (em unidades de tempo) Ordem
A 10 1
B 4 2
C 3 3
Figura 6.1: Escalonamento FIFO.

0+10+14 24
O tempo médio de resposta então, é Tm = 3 = 3 = 8 u.t.
6.2.1.2 SJF (Shortest Job First)

• A fila de execução é rearranjada de forma que a ordem de execução seja do processo que gasta menos
tempo para o processo que usa mais tempo de UCP.
• O tempo médio de resposta é baixo.
• É muito complicado prever quem é o menor de todos.
• Em sistemas interativos, é imprevisível.
Exemplo: Temos os mesmos 3 processos a serem executados, só que agora, a ordem de execução está de
acordo com o processo mais rápido para o processo mais lento:

A 10 3
B 4 2
C 3 1
Figura 6.2: Escalonamento SJF.
0+3+7 10
O tempo médio de resposta então, é Tm = 3 = 3 = 3, 3 u.t.
6.2.1.3 Cooperativo
• Um processo pode ficar em execução o tempo que quiser.
• Ele voluntariamente volta à fila de prontidão ou interrompe a sua execução, liberando a UCP.
• Foi usado em ambientes operacionais, com o Windows (das versões 1.0 à 3.11.
• Situações indesejadas podem ocorrer, como a não liberação da UCP.
6.2.2 Preemptivos
• O sistema operacional interrompe o processo e coloca outro em execução.
6.2.2.1 Circular
• Mais conhecido de todos.
• Muitas variações.
• Conceito de fatia de tempo.
• Não há monopólio de UCP.
• Processos CPU-Bound são privilegiados em detrimento de processos I/O-Bound.
• Problema da escolha de fatia de tempo:
– Se for muito pequena, muitas preempções, e o sistema operacional passa mais tempo escalonando
do que executando.
– Se for muito grande, torna-se um escalonamento FIFO, na prática.
• Uso de uma 2ª fila, de prontidão, para o processo I/O-Bound, que tem preferência para entrar em execução
do que os processos CPU-Bound – torna o balanceamento mais equilibrado (fatia de tempo menor).
Exemplo: Temos os mesmos 3 processos a serem executados, com uma fatia de tempo de 2 u.t.:

A 10 1
B 4 2
C 3 3
Figura 6.3: Escalonamento Circular.
0+2+4+6+8+10+11 41
O tempo médio de resposta então, é: Tm = 7 = 7 = 5, 8 u.t.
6.2.2.2 Prioridades
• Baseado num valor associado, a prioridade: maior prioridade, melhor lugar na fila de execução.
• Não há preempção por tempo, a mudança é voluntária, ou um processo de prioridade maior vai para o
estado de prontidão, e toma o lugar do outro na execução.
• Pode também ser não-preemptivo

• A prioridade pode ser:
– Estática – não muda.

– Dinâmica – muda ao longo do tempo.
• Risco de starvation, o que pode ser evitado com prioridade dinâmica.
Exemplo: Temos os mesmos 3 processos a serem executados:

Processo Tempo de UCP (em unidades de tempo) Prioridade
A 10 2
B 4 1
C 3 3
Figura 6.4: Escalonamento por prioridades.
0+3+13 16
O tempo médio de resposta então, é: Tm = 3 = 3 = 5, 3 u.t.
6.2.2.3 Circular com Prioridades

• Aqui, une-se conceitos de prioridade associada ao processo e fatia de tempo, logo o processo fica em
execução até que:
1. Ocorra uma preempção por :

(a) Tempo
(b) Prioridade
2. Ou o processo encerre a sua execução.
• Este escalonamento é amplamente usado, permitindo melhor balanceamento no uso da UCP.
6.2.2.4 Múltiplas filas

• Várias filas de execução, cada uma com uma prioridade.
• Os processos são associados as filas em função de suas características.
• Cada fila pode ter um mecanismo próprio de escalonamento
• Se o processo mudar de comportamento, ele não pode mudar de fila
6.2.2.5 Múltiplas filas com realimentação

• Aqui, os processos podem trocar de fila durante o processamento.
• Mecanismo de ajuste dinâmico, ou adaptativo.
Exemplo: várias filas:
• Escalonamento com fatias de tempo diferentes para cada fila
1. Processos I/O Bound - ficam nas filas com maior prioridade.

2. Processos CPU-Bound - começam na fila de alta prioridade, é executado e “desce” para uma fila de
menor prioridade.
• Quanto mais tempo o processo usa da UCP, mais ele cai para filas de menor prioridade.
• Problemas:
1. Se o comportamento do processo mudar (CPU-Bound para I/O-Bound, por exemplo), isso compro-
mete o tempo de resposta.
2. Algoritmo muito complexo, e consequentemente, lento.
6.3 Politicas de Escalonamento

6.3.1 Tempo Compartilhado
• Processamento interativo, na maioria dos casos.
• Compartilhamento dos recursos de forma equilibrada.
Exemplos:
• FIFO →Processo CPU-Bound leva clara vantagem.
• Circular → Mais equilibrado – depende do tamanho da fatia.
– Muito grande → vira FIFO.

– Muito pequeno → fica mais tempo trocando de contexto do que executando o processo.
• Circular com prioridades →Para compensar, associa-se prioridades maiores para os processos I/O-Bound.
Fica mais refinado se as prioridades forem dinâmicas – mais adotado hoje em dia.
• Deve-se levar em conta que algumas operações de E/S são mais lentos do que outras
6.3.2 Tempo Real

• Algumas aplicações exigem respostas imediatas, ou em intervalo de tempo rígidos.
• Uso de escalonamento por prioridades – prioridade estática.
• Alguns sistemas tem uma taxa de prioridade onde neles ocorre exclusivamente a preempção por priori-
dade.

Sistemas Operacionais 1 - Notas de Aula

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistemas Operacionais 1 - Notas de Aula

Uploaded by

Copyright:

Available Formats

Sistemas Operacionais 1 - Resumo

Prof. Ricardo Pinheiro

3 Estrutura do sistema operacional 14

3.5 Tipos de kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Sincronização entre processos 25

5.6.2 Soluções por software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.1 O que é um Sistema Operacional (SO)?

• Executado de forma não-seqüencial.

3. Administração de usuários da máquina (usuários = programas, pessoas).

2. Facilitar o acesso aos recursos.

OBS: Recursos → UCP, memória, HD ....

1.2 Máquina de Níveis

1. São independentes entre si.

2. A passagem por cada uma é obrigatória.

3. Há uma interface entre as camadas.

1.3 Tipos de Sistemas Operacionais

3. Estrutura interna – complexidade

1.3.1 Sistemas Monotarefa

• Todos os recursos dedicados a esse programa - desperdício

Ex: MS-DOS, PALM OS

1.3.2 Sistemas Multitarefa

• Compartilhamento e gerência dos recursos.

• Alguns são multiusuário.

1.3.2.1 Lote ou Batch

• fila de submissão de tarefas

• tarefas não interativas

• Saída em impressora ou disco

• Não são mais usados

1.3.2.2 Tempo Compartilhado (Time-Share)

• Conceito de fatia de tempo

Ex: UNIX, WINDOWS

1.3.2.3 Tempo Real (Real-Time)

• Tempo de resposta → dentro de intervalos rígidos.

• Prioridade definida pela aplicação.

1.3.3 Multiplas UCP´s

2. Problemas mais caros computacionalmente.

3. ”Lei” de Moore – limite físico.

1. uso de arquiteturas com mais de uma UCP

2. software que tire proveito e escalone entre as UCP´s presentes

3. balanceamento de carga – justo

5. imagem única do sistema

1.3.3.1 Multiprocessadores, ou sistemas fortemente acoplados

• Tudo gerênciado por um único SO.

SMP - Arquitetura simétrica.

NUMA - Acesso Não-Uniforme a Memória.

• Custo de produção mais elevado.

1.3.3.2 Multicomputadores, ou sistemas fracamente acoplados.

• Custo de produção mais baixo.

• Objetivo: minimizar o desperdício (tempo que a UCP fica parada)

– Frequência da UCP é maior do que a frequência da memória

Exemplo: Programa pega 100 registros, ordena e grava o resultado:

Operação Uso Tempo

• Evento é externo ao programa.

• Arquitetura IBM-PC: 16 interrupções de hardware, divididas entre 2 controladoras de interrupção (inter-

• Há a necessidade de termos mecanismos apropriados para cada tipo de interrupção.

• Como são tratadas:

– Rotina de tratamento de interrupção

– Mascaráveis – podem ser ignoradas.

• Controlador de pedidos de interrupção - Hardware que gerencia as interrupções.

– Evento interno ao programa.

Exemplo: Divisão por zero, buffer overflow, stack overflow, etc.

• Tratamento feito pelo desenvolvedor, ou pelo hardware (em alguns casos).

– Falhas em programas geram exceções.