Professional Documents
Culture Documents
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
1
SUMÁRIO 2
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
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
• Conjunto de rotinas.
1.1.1 Funções:
1. Interação homem-máquina.
2. Gerência de recursos.
1.1.2 Objetivos
1. Compartilhar os recursos de forma organizada e protegida.
• 6 níveis:
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. Aplicação
2. Hardware empregado
• Desejável:
1. Escalável
2. Rápido
3. Flexível
4. Seguro
5. Tolerante a Falhas
6. Robusto
• Estrutura simples
• Melhor aproveitamento.
• Estrutura complexa.
• Podem ser eficientes, como também podem ter tempos de resposta longos
• Cada tarefa fica em execução até o tempo acabar, dando lugar a outra
• Tarefas interativas
• Conceito de prioridade →tarefa em execução enquanto não houver outro de mais prioridade do que ele
• Uso em sistemas de missão critica e controle de processos: refinarias, siderúrgicas, trafego aéreo.
CAPÍTULO 1. INTRODUÇÃO 7
• Conceitos:
1. escalabilidade
2. disponibilidade
3. balanceamento de carga
• tendência atual
• Problemas:
1. Necessidade de desempenho
• Solução:
• Caracteristicas desejáveis:
1. escalabilidade – alta
2. disponibilidade – alta
4. transparência
• Subdividido em
• Um único SO ou vários
• Cada membro do sistema esta conectado aos outros por um link de dados
• Tendência atual
Capítulo 2
Concorrência
2.1 Introdução
• Computador - seu uso é caro computacionalmente
• Momentos de desperdício:
• Solução: Manter a UCP o mais ocupada possível, executando instruções de forma concorrente.
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
• A interrupção é o fundamento básico de concorrência, usado para a sincronização das rotinas do S. O.,
programas, etc.
Exemplo: IRQ1 - relógio (timer); IRQ3 - porta serial 1; IRQ7 - porta paralela; IRQ13 - IDE 1; etc.
• 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:
2.3 Exceções
• Parecidos com as interrupções, mas diferem nos quesitos:
• Segurança:
• Problema ainda existe →a transferência de dados entre a memória e dispositivo de E/S é feita pela UCP.
• ”Interferência” da UCP.
2.4.3 Polling
• 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.
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.
CAPÍTULO 2. CONCORRÊNCIA 13
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.
2. Bibliotecas.
3. Utilitários.
3.1 Kernel
• núcleo do sistema.
• execução não-sequencial.
• Principais funções:
• Tipos de kernel: como ele fala com o hardware e software, sua organização interna varia de projeto para
projeto.
14
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 15
3.2 Bibliotecas
• Conjunto de rotinas usadas por programas.
• Programa→System Calls→Kernel→Hardware
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.
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.
3.5.1 Monolítico
• Um grande bloco de código, ou dividido em módulos, todos sendo executados no modo kernel.
• A manutenção pode ser complexa, se não for um projeto bem-feito e bem amarrado.
• Simples na estrutura.
• Rápido.
3.5.2 Camadas
• Níveis sobrepostos.
• 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.
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 17
• Cada máquina virtual é independente das demais, contendo seu próprio sistema operacional, seus pró-
prios usuários e suas próprias aplicações.
• Vantagens:
• 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.
• 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:
• 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.
Processos e threads
4.1 Introdução
• Conceito - base para a implementação de um sistema multiprogramável.
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
Escalonamento: Conjunto de critérios que definem qual processo será colocado em execução primeiro.
• Mudanças:
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.
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.
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.
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.
Exemplos: Notificação de interrupções e exceções, alarmes de tempo, limites de quotas excedidos, etc.
• 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.
• 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.
4.9.2.2 Multithread
• Permite que tenhamos aplicações concorrentes de forma mais eficiente:
• 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.
• É desejável unir o melhor das implementações, fugindo dos problemas de cada uma.
• 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.
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.
• Podem ocorrer situações indesejáveis, que podem até comprometer a execução da aplicação.
• 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
25
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 26
• Ao invés de usar BEGIN e END como delimitadores de bloco, usa-se PARBEGIN e PAREND.
• Suponhamos então, 2 processos (Caixa 1 e Caixa 2) realizando operações na conta desse cliente.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 27
• 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.
• 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.
• 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.
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.
• Condições:
• Maneira simples.
• Atrapalha a multiprogramação.
• Múltiplas UCPs - Essa informação (de desligamento e religamento) deve propagar para todas as UCPs.
– 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:
5.6.2.1 Algoritmo 1
• 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
• Substituição da variável de bloqueio por duas variáveis, uma para cada processo.
• Se houver um problema, o recurso não fica bloqueado, a não ser que a falha seja dentro da região crítica.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 34
5.6.2.3 Algoritmo 3
• 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.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 35
• 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
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 36
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.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 37
– 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.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 38
– 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.
• Limitações:
• Deadlock
• 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.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 40
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
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 41
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.
• 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
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 42
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:
2. Se tirarmos a condição 2, quem tem recursos, tem que liberar para poder pegar novos recursos.
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.
CAPÍTULO 5. SINCRONIZAÇÃO ENTRE PROCESSOS 43
• 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.
• 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.
• Maximizar o throughput.
6.1.2 Partes
• escalonador (scheduler) – decide.
• dispatcher – executa.
6.1.3 Critérios
• uso da UCP – em porcentagem.
• 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.
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:
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.
6.2.2 Preemptivos
• O sistema operacional interrompe o processo e coloca outro em execução.
CAPÍTULO 6. GERÊNCIA DA UCP 47
6.2.2.1 Circular
• Mais conhecido de todos.
• Muitas variações.
– 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.:
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.
0+3+13 16
O tempo médio de resposta então, é: Tm = 3 = 3 = 5, 3 u.t.
• 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.
• 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