FSO Aula01

Prévia do material em texto

FUNDAMENTOS DE 
SISTEMAS 
OPERACIONAIS
Apresentação
Prof. Gabriel Fernandes
gfernandes@gmail.com
Bibliografia
• Bibliografia Básica:
• MACHADO, F. B.; MAIA, L. P.. Arquitetura de Sistemas Operacionais. 
4. ed. Rio de Janeiro: LTC, 2007.
• SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G.. Sistemas 
operacionais com Java. Rio de Janeiro: Elsevier, 2008.
• TANENBAUM, A. S. Sistemas Operacionais Modernos. São Paulo : 
Prentice-Hall.
• Bibliografia Complementar:
• DEITEL, H. M., DEITEL, P.J., CHOFINES, D.R. Sistemas 
Operacionais. São Paulo : Pearson Prenticce-Hall.
• OLIVEIRA, R. S., CARISSIMI, A. S., TOSCANI, S. S. Sistemas 
Operacionais. Porto Alegre : Instituto de Informática da UFRGS: 
Editora Sagra Luzzatto.
• TANENBAUM, A. S., WOODHULL. Sistemas Operacionais: projeto e 
implementação. 2a. ed.. Porto Alegre : Bookman.
SISTEMAS 
OPERACIONAIS
Parte 1 – Introdução e conceitos
Introdução
• Sistema computacional: conjunto de recursos 
computacionais, parte hardware e parte software
• Essencialmente, um sistema computacional consiste em:
• hardware;
• programas do sistema;
• programas de aplicação.
Motivos
• Sistemas de computadores modernos são compostos por 
diversos dispositivos:
• Processadores;
• Memória;
• Controladoras;
• Monitor;
• Teclado;
• Mouse;
• Impressoras;
• Outros...
Motivos
• Com tantos dispositivos, surge a necessidade de 
gerenciamento e manipulação desses diversos 
dispositivos
• Tarefa difícil à Sistemas Operacionais
Sistema Operacional
• Software responsável por gerenciar dispositivos que 
compõem um sistema computacional e realizar a 
interação entre o usuário e esses dispositivos;
• Hardware
• Processador;
• Memória Principal;
• Dispositivos de Entrada/Saída; 
• Software
• Programas de Aplicação;
• Programas do Sistema;
Sistema Operacional
• Sistema Operacional: software que controla os recursos 
do sistema computacional e oferece ao usuário uma 
interface para interagir com cada um destes recursos.
O que é um SO
• É uma máquina estendida (abordagem top- down, 
“abstração do todo para as partes”)
• Oculta os detalhes complicados que têm quer ser executados;
• Apresenta ao usuário uma máquina virtual, mais fácil de usar;
• É um gerenciador de recursos (abordagem bottom-up 
“abstração das partes para o todo”)
• Gerencia todas as partes de um sistema complexo ◦ Cada 
programa tem um tempo com o recurso;
• Cada programa tem um espaço no recurso.
SO como Máquina Estendida
• Ex.: como é feita a entrada/saída de um disco – tarefa: 
Leitura e Escrita
• SO: baixo nível
• Número de parâmetros;
• Endereço de bloco a ser lido;
• Número de setores por trilha;
• Modo de gravação;
• Usuário: alto nível – abstração simples
• Visualização do arquivo a ser lido e escrito;
• Arquivo é lido e escrito;
• Arquivo é fechado.
SO como Gerenciador de Recursos
• Gerenciar todos os dispositivos e recursos disponíveis no 
computador
• Ex.: se dois processos querem acessar um mesmo recurso, por 
exemplo, uma impressora, o SO é responsável por estabelecer 
uma ordem para que ambos os processos possam realizar sua 
tarefa de utilizar a impressora.
• Uso do HD;
• Uso da memória;
• Coordena a alocação controlada e ordenada dos 
recursos;
Objetivos de um SO
• Apresentar ao usuário do computador uma forma amena 
de utilizar a máquina. Criar uma máquina virtual, de fácil 
compreensão para o usuário, com características 
diferentes da máquina física;
• Realizar o melhor uso possível do hardware disponível, 
aumentando o desempenho do sistema e diminuindo o 
custo.
Histórico de Evolução (1ª Geração)
• Final dos anos 40: primeiro computador eletrônico: 
ENIAC (Electronic Numerical Integrator And Computer);
• 1950: surgem os cartões perfurados
• Os programas eram codificados nos cartões e sua leitura era feita 
por máquina à operadores de máquina;
• John von Neumann propõe uma programação não 
“hardwired”: nasce o Assembler/Assembly;
Histórico de Evolução (2ª Geração)
• Segunda Geração (1955-1965) – Transistores e Sistemas 
em Batch
• O desenvolvimento dos transistores tornou o computador mais 
confiável possibilitando sua comercialização - Mainframes;
• Separação entre projetistas, fabricante, programadores e técnicos 
de manutenção;
• No entanto, devido aos altos custos, poucos tinham acesso a essa 
tecnologia – somente grandes empresas, órgãos governamentais 
ou universidades;
Histórico de Evolução (2ª Geração)
• Surge a idéia de linguagem de programação de alto nível 
– Fortran (desenvolvida pela IBM – 1954-1957);
• Cartões perfurados ainda são utilizados
• Operação: cada programa (job) ou conjunto de programas escrito e 
perfurado por um programador era entregue ao operador da má
quina para que o mesmo fosse processado – alto custo
• Sistemas em Batch (lote)
• Consistia em coletar um conjunto de jobs e fazer a gravação desse 
conjunto para uma fita magnética
Histórico de Evolução (2ª Geração)
• Job em FORTRAN
Histórico de Evolução (3ª Geração)
• Terceira Geração (1965-1980) – Circuitos integrados e 
Multiprogramação
• Produtos incompatíveis
• Máquinas grandes orientadas a palavras (7094);
• Máquinas comerciais orientadas a caracteres (1401).
• Alta carga de desenvolvimento e manutenção
• IBM introduz o System/360
Histórico de Evolução (3ª Geração)
• System/360
• Série de máquinas com software compatível;
• Essas máquinas diferiam apenas no preço e desempenho, 
variando da 1401 até a 7094;
• Foi a primeira a usar circuito integrado em pequena escala, ao invé
s de transistores;
• O sistema operacional era o OS/360
• Sua maior vantagem era também sua maior fraqueza: SO enorme e 
muito complexo, pois precisava realizar as funções de todas as má
quinas. Era ineficiente, cheio de erros (milhões de linhas de código 
assembly escritas por milhares de programadores = milhares de erros)
Histórico de Evolução (3ª Geração)
• Aplicações que eram CPU-bound não tinham problema 
com relação ao tempo que se precisava esperar para 
realizar E/S;
• Aplicações que eram IO-bound gastavam de 80 a 90% do 
tempo realizando E/S
• Enquanto isso, a CPU ficava parada
• Solução: Multiprogramação
Histórico de Evolução (3ª Geração)
• Multiprogramação:
• Dividir a memória em diversas partes e alocar a cada uma dessas 
partes um job.
• Manter na memória simultaneamente uma quantidade de jobs 
suficientes para ocupar 100% do tempo do processador, 
diminuindo a ociosidade.
• Importante: o hardware é que protegia cada um dos jobs contra 
acesso indevidos de outros jobs.
Histórico de Evolução (3ª Geração)
• Spooling (Simultaneous Peripheral Operation On Line):
• Possibilitar que a leitura de cartões de jobs fosse feita direta do 
disco;
• Assim que um job terminava, o sistema operacional já alocava o 
novo job à uma partição livre da memória direto do disco;
• Eliminação de máquinas como as 1401 e a necessidade de se 
ficar andando entre as máquinas.
Histórico de Evolução (3ª Geração)
• Mesmo com o surgimento de novas tecnologias, o tempo 
de processamento ainda era algo crítico. Para corrigir um 
erro de programação, por exemplo, o programador 
poderia levar horas pois cada job era tratado dentro de 
um lote
• Timesharing
Histórico de Evolução (3ª Geração)
• Timesharing: cada usuário tinha um terminal on-line à 
disposição;
• Primeiro sistema Timesharing: CTSS (Compatible Time Sharing 
System) – Sistema 7094 modificado.
• Ex.: se entre 20 usuários,17 estão ausentes ou ociosos, o 
processador é alocado a cada um dos 3 jobs que estão sendo 
executados;
Histórico de Evolução (3ª Geração)
• Surge o MULTICS (Multiplexed Information and 
Computing Service), predecessor do UNIX;
• Fruto de uma idéia do MIT,Bell Labs e General Electric, de 
desenvolver um computador que suportasse centenas de usuários 
simultan̂eos em timesharing
• Codificado em PL/I, o que atrapalhou seu desenvolvimento 
(compilador fraco)
• Apesar do fracasso comercial, teve enorme influen̂cia em SO’s 
futuros
• Família de minicomputadores PDP da DEC;
• Diferente da família System/360, eram incompatíveis;
• Unix original rodava no PDP-7 (Ken Thompson – cientista da Bell 
Labs)
• O PDP-1 custava $120 mil (5% do valor de um 7094)
• Tinha 4K (mil) palavras de 18 bits
Histórico de Evolução (4ª Geração)
• Quarta Geração (1980-1990) – Computadores Pessoais
• Com a tecnologia de circuitos integrados de larga escala (LSI) 
surgem chips com milhares de transistores encapsulados em um 
centímetro quadrado de silício
• Intel – 8080 (1974)
• IBM – PC (início dos anos 80)
• Apple – Apple e Macintosh
Histórico de Evolução (4ª Geração)
• Intel 8080 – CP/M da Digital Research Gary Kildall)
• CP/M (Control Program for MicroComputer) – sistema operacional 
baseado em disco;
• IBMPC- DOS
• Inicialmente, a IBM tentou utilizar o CP/M, mas Kildall não quis 
nenhum acordo;
• IBM procurou Bill Gates pedindo um sistema operacional para 
rodar e ser vendido juntamente com o IBM PC;
• Bill Gates comprou a empresa que desenvolvia o DOS (Disk 
Operating System): Seattle Computer Products; Desenvolvedor: 
Tim Paterson;
Histórico de Evolução (4ª Geração)
• Evolução do DOS: MS-DOS (MicroSoft DOS)
• Tanto o CP/M quanto o MS-DOS eram baseados em comandos;
• Macintosh Apple - Sistemas baseados em janelas (GUI – 
Graphical User Interface)
• Microsoft – Plataforma Windows
• A história deste período da computação está muito bem 
retratada no filme “Piratas da Informática” (“Pirates of 
Sylicon Valley”) e no documentário “O Triunfo dos Nerds”
Histórico de Evolução (5ª Geração, 1990-
hoje)
• Era da computação distribuída: um processo é dividido 
em subprocessos que executam em sistemas 
multiprocessados e em redes de computadores ou 
mesmo em sistemas virtualmente paralelos
Histórico de Evolução (5ª Geração, 1990-
hoje)
• O protocolo de comunicações TCP/IP tornou-se 
largamente utilizado (Depto. de Defesa dos EUA) e as 
LANs (Local Area Networks) tornaram-se mais práticas e 
econom̂icas com o surgimento do padrão Ethernet, 
desenvolvido pela Xerox;
• Desenvolvimento e popularização do modelo 
cliente/servidor;
• Difusão das redes de computadores
• Internet
Histórico de Evolução (5ª Geração, 1990-
hoje)
• Sistemas Operacionais Distribuídos:
• Apresenta-se como um sistema operacional centralizado, mas que, 
na realidade, tem suas funções executadas por um conjunto de má
quinas independentes;
• Sistemas Operacionais em Rede;
• Usuários conhecem a localização dos recursos que estão 
utilizando e não tem̂ a visão de um sistema centralizado;
• Sistema Operacionais para dispositivos móveis;
• Execução de tarefas com economia de energia (baterias limitadas), 
aplicações voltadas principalmente para web
• Unix → Minix → Linux;
• Família Windows (NT, 95, 98, 2000, XP, Vista,7, 8);
• Apple iOS, Android, WinCE → WP 7 → WP 8
Resumo do Histórico
• Primeira geração – anos 50
• Válvulas, painéis de programação; processamento em lotes
• Segunda geração – anos 60
• Multiprogramação, multiprocessamento, timesharing, tempo real
• Terceira geração – meados 60 a meados 70
• Sistemas de propósito geral; desenvolvimento em linguagens de 
alto nível
• Quarta geração – meados 70 a meados 80
• Cliente/servidor, processamento distribuído, interface gráfica
• Quinta geração – meados 80 aos dias atuais
• Redes, computação distribuída, software livre
Tipos de SO
• Sistemas operacionais de computadores de grande porte;
• Sistemas operacionais de servidores;
• Sistemas operacionais de multiprocessadores;
• Sistemas operacionais de computadores pessoais;
• Sistemas operacionais de tempo real;
• Sistemas operacionais embarcados;
• Sistemas operacionais de cartões inteligentes;
• Sistemas operacionais para dispositivos móveis
Arquiteturas de SO
• Arquitetura Monolítica
• Todos os componentes do SO estão contidos no núcleo, 
comunicando-se diretamente entre si;
• Rapidez na comunicação, mas complexidade no código.
• Arquitetura em Camadas
• Componentes autocontidos, em camadas de componentes que 
realizam tarefas similares;
• Pior desempenho que a monolítica.
Arquiteturas de SO
• Arquitetura de Micronúcleo
• Também é uma forma de arquitetura em camadas (modular);
• Somente uma pequena parte dos serviços pode acessar 
diretamente o Hardware
• Aplicações
• Kernel, Chamadas ao Sistema
• Serviços do MicroKernel, MicroKernel
• Hardware
Tipos de serviço do S.O.
• O SO fornece um ambiente para a execução de 
programas através de serviços para os programas e para 
os usuários desses programas
• Apesar da forma como esses serviços são oferecidos 
variar de sistema para sistema, existem algumas classes 
de serviços que são comuns a todos os sistemas 
operacionais
Tipos de Serviço de SO
• Serviços mais comuns gerenciados pelo S.O.:
• Execução de programas;
• Operações de entrada/saída;
• Manipulação de sistema de arquivos;
• Detecção de erros;
• Alocação de recursos;
• Proteção.
Conceitos Básicos de SO
• Principais conceitos:
• Processo;
• Memória;
• Chamadas de Sistema;
Processos
• Processo: chave do SO;
• Caracterizado por programas em execução;
• Cada processo possui:
• Um espaço de endereço;
• Uma lista de alocação de memória (mínimo, máximo);
• Um conjunto de registradores (contador de programa);
• O Sistema Operacional controla todos os processos.
Processos
• Estados básicos de um processo:
Em Execução
ProntoBloqueado
1- Bloqueio aguardando entrada 2 – Escalonador seleciona
outro processo
3 – Escalonador seleciona
esse processo
4 – Entrada disponível
Processos
• Ex: Processo bloqueado (suspenso)
• Quando o SO suspende um processo P1 
temporariamente para executar um processo P2, o 
processo P1 deve ser reiniciado exatamente no mesmo 
estado no qual estava ao ser suspenso.
• Para tanto, todas as informações a respeito do processo 
P1 são armazenadas em uma tabela de processos 
(process table). Essa tabela é um vetor ou uma lista 
encadeada de estruturas.
Processos
• Um processo pode resultar na execução de outros 
processos, chamados de processos-filhos:
• Características para a hierarquia de processos:
• Comunicação (Interação) e Sincronização;
• Segurança e proteção;
• Uma árvore de no máximo três níveis;
• Escalonadores de processos – processo que escolhe 
qual será o próximo processo a ser executado;
• Diversas técnicas para escalonamento de processos.
Processos
• A comunicação e sincronismo entre processos é um 
problema complexo, mas com diversas soluções 
possíveis (e que serão analisadas nas próximas aulas), 
que são:
• Semáforos;
• Monitores;
• Instruções especiais em hardware;
• Troca de mensagens;
Gerenciamento de Memória
• Gerenciamento elementar (década de 60)
• Sistema monoprogramado;
• Sem paginação:
• Apenas um processo na memória;
• Acesso a toda a memória;
• Gerenciamento mais avançado (atualidade)
• Sistema multiprogramado;
• Mais de um processo na memória;
• Chaveamento de processos: por entrada/saída ou por limite de 
tempo (sistema de tempo compartilhado);
Compartilhamento de Memória
• Partições Fixas
• Cada processo é alocado em uma dada partição da memória (pré-
definida);
• Partições são liberadas quando o processo termina;
• Partições Variáveis
• Memória é alocada de acordo com o tamanho e número de 
processos;
• Otimiza o uso da memória;
Comunicação entre usuário e o SO
• Chamadas ao Sistema (system calls) fornecem uma 
interfaceentre um programa em execução e o S.O. 
Estão, geralmente, disponíveis como instruções nas 
linguagens de baixo nível ou até mesmo em linguagens 
de alto nível, como C.
• Podem ser classificadas em duas categorias:
• Controle de processos.
• Gerenciamento de arquivos e de dispositivos de E/S.
Chamadas ao Sistema
• Modos de Acesso:
• Modo usuário;
• Modo kernel ou Supervisor ou Núcleo;
• São determinados por um conjunto de bits localizados no 
registrador de status do processador: PSW (program status word);
• Por meio desse registrador, o hardware verifica se a instrução pode ou 
não ser executada pela aplicação;
• Protege o próprio kernel do Sistema Operacional na RAM contra 
acessos indevidos;
Chamadas ao Sistema
• Modo usuário:
• Aplicações não têm acesso direto aos recursos da máquina, ou 
seja, ao hardware;
• Quando o processador trabalha no modo usuário, a aplicação só 
pode executar instruções sem privilégios, com um acesso 
reduzido de instruções;
• Por que? Para garantir a segurança e a integridade do sistema;
Chamadas ao Sistema
• Modo Kernel:
• Aplicações têm acesso direto aos recursos da máquina, ou seja, 
ao hardware;
• Operações com privilégios;
• Quando o processador trabalha no modo kernel, a aplicação tem 
acesso ao conjunto total de instruções;
• Apenas o SO tem acesso às instruções privilegiadas;
Alternando entre modos
• Se uma aplicação precisa realizar alguma instrução 
privilegiada, ela realiza uma chamada ao sistema 
(system call), que altera do modo usuário para o modo 
kernel;
• Chamadas de sistemas são a porta de entrada para o 
modo Kernel;
• São a interface entre os programas do usuário no modo usuário e 
o Sistema Operacional no modo kernel;
• As chamadas diferem de SO para SO, no entanto, os 
conceitos relacionados às chamadas são similares 
independentemente do SO;
Execução de chamadas ao sistema
• TRAP: instrução que permite o acesso ao modo kernel;
• Exemplo:
• Instrução do UNIX:
count = read(fd,buffer,nbytes);
Arquivo, ponteiro para o buffer, número de bytes
O programa sempre deve checar o retorno da chamada 
de sistema para saber se algum erro ocorreu.
Exemplos de chamadas ao sistema
Exemplos de chamadas ao sistema
Chamadas ao Sistema API (application
program interface) WIN32
ESTRUTURA DOS 
SISTEMAS 
OPERACIONAIS
Estrutura dos SOs
• Principais tipos de estruturas:
• Monolíticos;
• Em camadas;
• Máquinas Virtuais;
• Arquitetura Micro-kernel;
• Cliente-Servidor.
Estrutura dos SOs - Monolítico
• Todos os módulos do sistema são compilados 
individualmente e depois ligados uns aos outros em um 
único arquivo-objeto;
• O Sistema Operacional é um conjunto de processos que 
podem interagir entre si a qualquer momento sempre que 
necessário;
• Cada processo possui uma interface bem definida com 
relação aos parâmetros e resultados para facilitar a 
comunicação com os outros processos;
• Simples;
• Primeiros sistemas UNIX e MS-DOS;
Estrutura dos SOs - Monolítico
Estrutura dos SOs - Monolítico
• Os serviços (chamadas) requisitados ao sistema são 
realizados por meio da colocação de parâmetros em 
registradores ou pilhas de serviços seguida da execução 
de uma instrução chamada TRAP;
59
Estrutura dos Sistemas Operacionais -
Monolítico
Programas de usuário
rodam em modo usuário
Rotinas do SO rodam em 
modo kernelProcedimentos de Serviço
Programa de usuário 2
Programa de usuário 1
Chamada ao sistema (kernel)
M
em
ór
ia
 P
rin
ci
pa
l
1
2
TRAP 3
Tabela de 
Escalonamento
4
Procedimentos de 
Serviços
Implementação de uma Chamada de Sistema
chaveamento da máquina do modo 
usuário para o modo kernel e 
transferência do controle para o Sistema 
Operacional
Sistema Operacional examina os 
parâmetros da chamada para determinar 
qual procedimento deve ser executado
SO indexa em uma tabela um 
ponteiro para o processo 
responsável pela execução
a chamada é concluída e o 
controle volta ao programa do 
usuário
60
Estrutura dos SOs – Em camadas
• Possui uma hierarquia de níveis;
• Primeiro sistema em camadas: THE (idealizado por E.W. 
Dijkstra);
• Possuía 6 camadas, cada qual com uma função diferente;
• Sistema em batch simples;
• Vantagem: isolar as funções do sistema operacional, 
facilitando manutenção e depuração
• Desvantagem: cada nova camada implica uma mudança 
no modo de acesso
• Atualmente: modelo de 2 camadas
61
Estrutura dos SOs – Em camadas
Fornecimento 
de Serviços
Camadas definidas no THE
62
Estrutura dos SOs – Máquina Virtual
• Idéia em 1960 com a IBM à VM/370;
• Modelo de máquina virtual cria um nível intermediário 
entre o SO e o Hardware;
• Esse nível cria diversas máquinas virtuais 
independentes e isoladas, onde cada máquina oferece 
uma cópia virtual do hardware, incluindo modos de 
acesso, interrupções, dispositivos de E/S, etc.;
• Cada máquina virtual pode ter seu próprio SO;
63
Estrutura dos SOs – Máquina Virtual
• Principais conceitos:
• Monitor da Máquina Virtual (VMM): roda sobre o hardware e 
implementa multiprogramação fornecendo várias máquinas 
virtuais à é o coração do sistema;
• CMS (Conversational Monitor System):
• TimeSharing;
• Executa chamadas ao Sistema Operacional;
• Máquinas virtuais são cópias do hardware, incluindo os modos 
kernel e usuário;
• Cada máquina pode rodar um Sistema Operacional diferente;
64
Estrutura dos SOs – Máquina Virtual
Instruções de E/S
Hardware (VMM)
VM/370
CMS CMSCMS
Cópias virtuais do 370s
TRAP
Chamadas ao sistema
TRAP
Monitor da Máquina Virtual
roda sobre o hardware e implementa 
multiprogramação
pTimeSharing;
pChamadas ao Sistema
Cada máquina pode rodar um 
Sistema Operacional diferente
65
Estrutura dos SOs – Máquina Virtual
• A idéia de máquina virtual foi posteriormente utilizada em 
contextos diferentes:
• Programas MS-DOS: rodam em computadores 32bits;
• As chamadas feitas pelo MS-DOS ao Sistema Operacional eram 
realizadas e monitoradas pelo monitor da máquina virtual (VMM);
66
Estrutura dos SOs – Máquina Virtual
• A idéia de máquina virtual foi posteriormente utilizada 
em contextos diferentes:
• Programas JAVA (Máquina Virtual Java-JVM): o compilador Java 
produz código para a JVM (bytecode). Esse código é executado 
pelo interpretador Java:
• Programas Java rodam em qualquer plataforma, independentemente 
do Sistema Operacional;
67
Estrutura dos SOs – Máquina Virtual
• A idéia de máquina virtual foi posteriormente utilizada em 
contextos diferentes:
• Computação em nuvem
• Virtualização dos servidores simula diferentes ambientes em 
servidores físicos
68
Estrutura dos SOs – Máquina Virtual
• Vantagens 
• Flexibilidade;
• Desvantagem:
• Simular diversas máquinas virtuais não é uma tarefa simples à
sobrecarga;
69
Estrutura dos SOs – Kernel
• Kernel é o núcleo do Sistema Operacional
• Provê um conjunto de funcionalidades e serviços que 
suportam várias outras funcionalidades do SO
• O restante do SO é organizado em um conjunto de 
rotinas não-kernel
70
Estrutura dos SOs – Micro-Kernel
Modo k ern e l
Modo u su á rio
Microk ern e l
m
en
sa
ge
m
m
en sagem
H ardw are
71
Estrutura dos SOs – Cliente/Servidor
• Reduzir o Sistema Operacional a um nível mais simples:
• Kernel: implementa a comunicação entre processos clientes e 
processos servidores à Núcleo mínimo;
• Maior parte do Sistema Operacional está implementado como 
processos de usuários (nível mais alto de abstração);
• Sistemas Operacionais Modernos;
72
Estrutura dos SOs – Cliente/Servidor
Cada processo servidor trata de uma tarefa
• Os processosservidores não têm acesso direto ao hardware.
Assim, se algum problema ocorrer com algum desses servidores,
o hardware não é afetado;
• O mesmo não se aplica aos serviços que controlam os
dispositivos de E/S, pois essa é uma tarefa difícil de ser realizada
no modo usuário devido à limitação de endereçamento. Sendo
assim, essa tarefa ainda é feita no kernel.
73
Estrutura dos SOs – Cliente/Servidor
• Adaptável para Sistemas Distribuídos;
74
Estrutura dos SOs – Cliente/Servidor
• Linux
• Monolítico +Módulos
• Windows
• Microkernel + Camadas + Módulos
FUNDAMENTOS DE 
SISTEMAS 
OPERACIONAIS
Aula 01 Parte 02 – Escalonamento de processos
Prof. Gabriel Fernandes
gfernandes@gmail.com
76
Processos 
• Multiprogramação:
• Pseudoparalelismo: coleção de processos sendo executados 
alternadamente na CPU;
• Um processo é caracterizado por um programa em 
execução, mas existe uma diferença sutil entre processo 
e programa:
• Um processo pode ser composto por vários programas, dados de 
entrada, dados de saída e um estado (executando, bloqueado, 
pronto)
77
Criando Processos
• Processos precisam ser criados e finalizados a todo o 
momento:
• Inicialização do sistema;
• Execução de uma chamada ao sistema de criação de processo 
realizada por algum processo em execução;
• Requisição de usuário para criar um novo processo;
• Inicialização de um processo em batch – mainframes com 
sistemas em batch;
78
Criando Processos
• Processos podem ser:
• Específicos para usuários específicos:
• Leitura de um arquivo;
• Iniciar um programa (linha de comando ou um duplo clique no mouse);
• Com funções específicas, que independem de usuários, que são 
criados pelo sistema operacional e que são processados em 
segundo plano (daemons):
• Recepção e envio de emails;
• Serviços de Impressão;
79
Criando Processos
• UNIX: 
• Fork;
• Cria um processo idêntico (filho) ao processo que a chamou (pai), 
possuindo a mesma imagem de memória, as mesmas cadeias de 
caracteres no ambiente e os mesmos arquivos abertos;
• Depois, o processo filho executa uma chamada para mudar sua 
imagem de memória e executar um novo programa
• Windows:
• CreateProcess
• Uma única função trata tanto do processo de criação quanto da carga 
do programa correto no novo processo
80
Criando Processos
• Exemplo UNIX:
• Processo init: gera vários processos filhos para atender os 
vários terminais que existem no sistema;
Outros 
processos
são gerados 
nos terminais
81
Finalizando Processos
• Condições:
• Término normal (voluntário):
• A tarefa a ser executada é finalizada;
• Chamadas: exit (UNIX) e ExitProcess (Windows)
• Término com erro (voluntário):
• O processo sendo executado não pode ser finalizado: gcc filename.c, o 
arquivo filename.c não existe;
82
Finalizando Processos
• Condições (continuação):
• Término com erro fatal (involuntário);
• Erro causado por algum erro no programa (bug): 
• Divisão por 0 (zero);
• Referência à memória inexistente ou não pertencente ao processo;
• Execução de uma instrução ilegal;
• Término causado por algum outro processo (involuntário):
• Kill (UNIX) e TerminateProcess (Windows);
Estados de Processos (relembrando)
• Estados básicos de um processo:
Em Execução
ProntoBloqueado
1- Bloqueio aguardando entrada 2 – Escalonador seleciona
outro processo
3 – Escalonador seleciona
esse processo
4 – Entrada disponível
84
Estados de Processos
Três estado básicos
Executando
Bloqueado Pronto
1 2
3
4
Um processo sendo 
executado não pode 
continuar sua execução, 
pois precisa de algum 
evento (E/S ou semáforo) 
para continuar;
85
Estados de Processos
Um processo é bloqueado 
de duas maneiras:
• chamada ao sistema:
block ou pause;
• se não há entradas 
disponíveis para que o 
processo continue sua 
execução; Executando
Bloqueado Pronto
1 2
3
4
86
Estados de Processos As transições 2 e 3 
ocorrem durante o 
escalonamento de 
processos: o tempo 
destinado àquele 
processo acabou e 
outro processo é 
colocado no 
processador;Executando
Bloqueado Pronto
1 2
3
4
87
Estados de Processos
A transição 4 ocorre quando o evento esperado
pelo processo bloqueado ocorre:
• se o processador está parado, o processo é
executado imediatamente (2);
• se o processador está ocupado, o processo
deve esperar sua vez;
Executando
Bloqueado Pronto
1 2
3
4
88
Processos
• Processos CPU-bound (orientados à CPU): processos 
que utilizam muito o processador;
• Tempo de execução é definido pelos ciclos de processador;
• Processos I/O-bound (orientados à E/S): processos que 
realizam muito E/S; 
• Tempo de execução é definido pela duração das operações de 
E/S;
• IDEAL: existir um balanceamento entre processos CPU-
bound e I/O-bound; 
89
Escalonador de Processos
Escalonador de Processos
0 n... n-11
Processos
• Nível mais baixo do SO;
• Manipulação de 
interrupções e processos;
90
Implementação de Processos
• Tabela de Processos:
• Cada processo possui uma entrada;
• Cada entrada possui um ponteiro para o bloco de controle de 
processo (BCP) ou descritor de processo;
• BCP possui todas as informações do processo à contextos de 
hardware, software, endereço de memória;
91
Implementação de Processos
Tabela de processos
...
BCP – P1
BCP – P2
BCP – Pn
...
92
Implementação de Processos
Algumas informações do BCP
93
Escalonamento de Processos
• Escalonador de Processos escolhe o processo que será 
executado pela CPU;
• Escalonamento é realizado com o auxílio do hardware;
• Escalonador deve se preocupar com a eficiência da CPU, 
pois o chaveamento de processos é complexo e custoso:
• Afeta desempenho do sistema e satisfação do usuário;
• Escalonador de processo é um processo que deve ser 
executado quando da mudança de contexto (troca de 
processo);
94
Escalonamento de Processos
• Mudança de Contexto:
• Overhead de tempo;
• Tarefa cara:
• Salvar as informações do processo que está deixando a CPU em seu 
BCP à conteúdo dos registradores;
• Carregar as informações do processo que será colocado na CPU à
copiar do BCP o conteúdo dos registradores;
95
Escalonamento de Processos
PC = 0BF4h
PID = 2
Estado = pronto
BCP-P2
CPU
PC = 074Fh
PC = 074Fh
PID = 4
Estado = executando
BCP-P4
Próximo processo
Antes da Mudança de Contexto
Processo já 
executou 
algumas 
instruções
96
Escalonamento de Processos
PC = 0BF4h
PID = 2
Estado = executando
BCP-P2
CPU
PC = 0BF4h
PC = 076Fh
PID = 4
Estado = pronto
BCP-P4
Depois da Mudança de Contexto
Salva o 
contexto 
no BCP
97
Escalonamento de Processos
• Situações nas quais escalonamento é necessário:
• Um novo processo é criado;
• Um processo terminou sua execução e um processo pronto deve 
ser executado;
• Quando um processo é bloqueado (semáforo, dependência de 
E/S), outro deve ser executado;
• Quando uma interrupção de E/S ocorre o escalonador deve decidir 
por: 
• executar o processo que estava esperando esse evento; 
• continuar executando o processo que já estava sendo executado;
• executar um terceiro processo que esteja pronto para ser executado.
98
Escalonamento de Processos
• Hardware de relógio fornece interrupções de relógio e a 
decisão do escalonamento pode ser tomada a cada 
interrupção ou a cada k interrupções;
• Algoritmos de escalonamento podem ser divididos em 
duas categorias dependendo de como essas interrupções 
são tratadas:
• Preemptivo: escolhe um processo e o deixa executando por um tempo 
máximo;
• Não-preemptivo: estratégia de permitir que o processoque está sendo 
executado continue sendo executado até ser bloqueado por alguma 
razão (semáforos, operações de E/S-interrupção) ou que libere a CPU 
voluntariamente;
99
Escalonamento de Processos
• Categorias de Ambientes:
• Sistemas em Batch: usuários não esperam por respostas rápidas; 
algoritmos não-preemptivos ou preemptivos com longo intervalo de 
tempo;
• Sistemas Interativos: interação constante do usuário; algoritmos 
preemptivos; Processo interativo à espera comando e executa 
comando; 
• Sistemas em Tempo Real: processos são executados mais 
rapidamente; tempo é crucial à sistemas críticos;
100
Escalonamento de Processos
• Características de algoritmos de escalonamento: 
• Qualquer sistema:
• Justiça (Fairness): cada processo deve receber uma parcela 
justa de tempo da CPU;
• Balanceamento: diminuir a ociosidade do sistema;
• Políticas do sistema – prioridade de processos;
101
Escalonamento de Processos
• Características de algoritmos de escalonamento: 
• Sistemas em Batch:
• Vazão (throughput): maximizar o número de jobs executados por 
hora;
• Tempo de retorno (turnaround time): tempo no qual o processo 
espera para ser finalizado; 
• Eficiência: CPU deve estar 100% do tempo ocupada;
• Sistemas Interativos:
• Tempo de resposta: tempo esperando para iniciar execução;
• Proporcionalidade: satisfação do usuários;
102
Escalonamento de Processos
• Características de algoritmos de escalonamento: 
• Sistemas em Tempo Real:
• Cumprimento dos prazos: prevenir perda de dados;
• Previsibilidade: prevenir perda da qualidade dos serviços oferecidos;
103
Escalonamento de Processos
Sistemas em Batch
• Escalonamento Three-Level
RAM
Escalonador da CPU *
Disco
Fila de entrada
Novo job
Escalonador
Da Memória
Escalonador
de Admissão
CPU
104
Escalonamento de Processos
Sistemas em Batch
• Escalonamento Three-Level
• Escalonador de admissão: decide qual job será admitido no 
sistema. Por exemplo, uma mescla de jobs orientados a CPU e 
orientados à E/S; processos com menor tempo de acesso à CPU e 
maior tempo de interação com dispositivos de E/S;
• Escalonador da Memória: decisões sobre quais processos vão 
para a MP:
• A quanto tempo o processo está esperando?
• Quanto tempo da CPU o processo já utilizou?
• Qual o tamanho do processo?
• Qual a importância do processo? 
• Escalonador da CPU: seleciona qual o próximo processo a ser 
executado;
Escalonamento de Processos
Turnaround
• Tempo de espera + tempo de execução
106
Escalonamento de Processos
Sistemas em Batch
• Algoritmos para Sistemas em Batch:
• First-Come First-Served (ou FIFO);
• Shortest Job First (SJF);
• Shortest Remaining Time Next (SRTN);
107
Escalonamento de Processos
Sistemas em Batch
• Algoritmo First-Come First-Served
• Não-preemptivo (permite que o processo que está sendo 
executado continue sendo executado até ser bloqueado por 
alguma razão); 
• Processos são executados na CPU seguindo a ordem de 
requisição;
• Fácil de entender e programar;
• Desvantagem:
• Ineficiente quando se tem processos que demoram na sua execução;
108
Escalonamento de Processos
Sistemas em Batch
• Algoritmo First-Come First-Served
Interrupção qualquer
(semáforo, E/S)
CPU
0
Fila de entrada
23 1
109
Escalonamento de Processos
Sistemas em Batch
• Algoritmo First-Come First-Served
CPU não controla o tempo dos processos!
(não-preemptivo)
CPU
1
Fila de entrada
30 2
110
Escalonamento de Processos
Sistemas em Batch
• Algoritmo Shortest Job First
• Não-preemptivo;
• Possível prever o tempo de execução do processo;
• Menor processo é executado primeiro;
• Menor turnaround;
• Desvantagem:
• Baixo aproveitamento quando se tem poucos processos prontos para 
serem executados;
111
Escalonamento de Processos
Sistemas em Batch
• Algoritmo Shortest Job First
A à a
B à b+a
C à c+b+a
D à d+c+b+a
__________________________________
Tempo médio-turnaround (4a+3b+2c+d)/4
Contribuição à se a<b<c<d tem-se o mínimo tempo 
médio;
112
Escalonamento de Processos
Sistemas em Batch
• Algoritmo Shortest Job First
A B C D
8 44 4
Em ordem:
Turnaround A = 8
Turnaround B = 12
Turnaround C = 16
Turnaround D = 20
Média à 56/4 = 14
B C D A
4 44 8
Menor job primeiro:
Turnaround B = 4
Turnaround C = 8
Turnaround D = 12
Turnaround A = 20
Média à 44/4 = 11
(4a+3b+2c+d)/4 Número deProcessos
113
Escalonamento de Processos
Sistemas em Batch
• Algoritmo Shortest Remaining Time Next
• Preemptivo (escolhe um processo e o deixa executando por um 
tempo máximo);
• Processos com menor tempo de execução são executados 
primeiro;
• Se um processo novo chega e seu tempo de execução é menor do 
que do processo corrente na CPU, a CPU suspende o processo 
corrente e executa o processo que acabou de chegar;
• Desvantagem: processos que consomem mais tempo podem 
demorar muito para serem finalizados se muitos processos 
pequenos chegarem!
114
Escalonamento de Processos
Sistemas Interativos
• Algoritmos para Sistemas Interativos:
• Round-Robin;
• Prioridade;
• Múltiplas Filas;
• Shortest Process Next;
• Garantido;
• Lottery;
• Fair-Share;
• Utilizam escalonamento em dois níveis (escalonador da 
CPU e memória);
115
Escalonamento de Processos
Sistemas Interativos
• Algoritmo Round-Robin
• Antigo, mais simples e mais utilizado;
• Preemptivo (escolhe um processo e o deixa executando por um 
tempo máximo);
• Cada processo recebe um tempo de execução chamado quantum; 
ao final desse tempo, o processo é suspenso e outro processo é 
colocado em execução;
• Escalonador mantém uma lista de processos prontos;
116
Escalonamento de Processos
Sistemas Interativos
• Algoritmo Round-Robin
Fila de prontos
G
D
A
B F
Fila de prontos
AG B
F D
Processo
corrente
Próximo
Processo
Lista após B utilizar seu
quantum
Processo
corrente
117
Escalonamento de Processos
Sistemas Interativos
• Algoritmo Round-Robin
• Tempo de chaveamento de processos;
• quantum: se for muito pequeno, ocorrem muitas 
trocas diminuindo, assim, a eficiência da CPU; 
se for muito longo o tempo de resposta é 
comprometido; 
118
Escalonamento de Processos
Sistemas Interativos
• Algoritmo Round-Robin:
Exemplos:
Dt = 4 ms
x = 1ms à 20% de tempo de CPU é 
perdido à menor eficiência
Dt = 99 ms
x = 1ms à 1% de tempo de CPU é 
perdido à Tempo de 
espera dos 
processos é 
maior
quantum
chaveamento
quantum razoável: 20-50 ms
119
Escalonamento de Processos
Sistemas Interativos
• Algoritmo com Prioridades
• Cada processo possui uma prioridade à os processos prontos 
com maior prioridade são executados primeiro;
• Prioridades são atribuídas dinâmica ou estaticamente;
• Classes de processos com mesma prioridade;
• Preemptivo (escolhe um processo e o deixa executando por um 
tempo máximo);
120
Escalonamento de Processos
Sistemas Interativos
• Algoritmo com Prioridades
1
2
3
4
mais alta
mais baixa
prioridade
FILAS
processos prontos
(Round-Robin)
121
Escalonamento de Processos
Sistemas Interativos
• Algoritmo com Prioridades
• Como evitar que os processos com maior prioridade sejam 
executado indefinidamente?
• Diminuir a prioridade do processo corrente a cada interrupção do 
relógio, e trocá-lo pelo próximo processo assim que sua prioridade caia 
abaixo da prioridade do próximo processo com prioridade mais alta 
(chaveamento);
• Atribuir um quantum máximo no qual o processo pode executar;
122
Escalonamento de Processos
Sistemas Interativos
• Múltiplas Filas:
• CTSS (Compatible Time Sharing System);
• Classes de prioridades;
• Preemptivo (escolhe um processoe o deixa executando por um 
tempo máximo); 
• Cada classe de prioridades possui quanta diferentes;
123
Escalonamento de Processos
Sistemas Interativos
• Múltiplas Filas:
• Assim, a cada vez que um processo é executado e suspenso ele 
recebe mais tempo para execução mas passa para uma fila com 
menor prioridade de execução
124
Escalonamento de Processos
Sistemas Interativos
• Múltiplas Filas:
• Ex.: um processo precisa de 100 quanta para ser executado; 
• Inicialmente, ele recebe um quantum para execução; 
• Das próximas vezes ele recebe, respectivamente, 2, 4, 8, 16, 32 e 64 
quanta (7 chaveamentos) para execução;
125
Escalonamento de Processos
Sistemas Interativos
• Algoritmo Shortest Process Next
• Mesma idéia do Shortest Job First;
• Processos Interativos: não se conhece o tempo necessário para 
execução;
• Solução: realizar uma estimativa com base no comportamento 
passado e executar o processo cujo tempo de execução estimado 
seja o menor;
126
Escalonamento de Processos
Sistemas Interativos
• Algoritmo Garantido:
• Garantias são dadas aos processos dos usuários
• Exemplo: n processos à 1/n do tempo de CPU para cada 
processo;
• Deve ser mantida taxa de utilização de cada 
processo
• Tem prioridade o que estiver mais distante do 
prometido
• Difícil de implementar
127
Escalonamento de Processos
Sistemas Interativos
• Algoritmo por Loteria:
• Cada processo recebe “tickets” que lhe dão direito de execução;
• A cada troca de processo um “ticket” é sorteado 
• O dono do “ticket” sorteado recebe o direito de ocupar a CPU
• Possível definir prioridade entre os processos por meio do número 
de “tickets” atribuído a cada processo
• Fácil de implementar e de adaptar
128
Escalonamento de Processos
Sistemas Interativos
• Algoritmo por Fração Justa (Fair-Share):
• O escalonamento é feito considerando o dono dos processos
• Cada usuário recebe uma fração da CPU e processos são 
escalonados visando garantir essa fração
• Se um usuário A possui mais processos que um usuário B e os dois 
têm a mesma prioridade, os processos de A demorarão mais que os 
do B
129
Escalonamento de Processos
Sistemas em Tempo Real
• Tempo é um fator crítico;
• Sistemas críticos:
• Aviões;
• Sistemas de suporte a vida (Hospitais);
• Usinas Nucleares;
• Bancos;
• Multimídia;
• Ponto importante: obter respostas em atraso é tão ruim 
quanto não obter respostas;
130
Escalonamento de Processos
Sistemas em Tempo Real
• Tipos de STR:
• Hard Real Time: atrasos não são tolerados;
• Aviões, usinas nucleares, hospitais;
• Soft Real Time: atrasos são tolerados;
• Bancos; Multimídia;
• Programas são divididos em vários processos;
• Eventos causam a execução de processos:
• Periódicos: ocorrem em intervalos regulares de tempo;
• Aperiódicos: ocorrem em intervalos irregulares de tempo;
131
Escalonamento de Processos
Sistemas em Tempo Real
• Algoritmos podem ser estáticos ou dinâmicos;
• Estáticos: decisões de escalonamento antes do sistema começar;
• Informação disponível previamente;
• Dinâmicos: decisões de escalonamento em tempo de execução;
THREADS
133
Processos
• Sistemas Operacionais tradicionais:
• Cada processo tem um único espaço de endereçamento e um 
único fluxo de controle
• Existem situações onde é desejável ter múltiplos fluxos 
de controle compartilhando o mesmo espaço de 
endereçamento:
• Solução: threads
134
Threads
• Um processo tradicional (pesado) possui um contador de programas, 
um espaço de endereço e apenas uma thread de controle (ou fluxo 
de controle);
• Multithreading: Sistemas atuais suportam múltiplas threads de 
controle, ou seja, pode fazer mais de uma tarefa ao mesmo tempo, 
servindo ao mesmo propósito;
a) Três processos b) Um processo com três threads
Thread Processo
• As três threads utilizam 
o mesmo espaço de endereço
135
Threads
• Thread é uma entidade básica de utilização da CPU
• Também são conhecidas como processos leves (lightweight 
process ou LWP);
• Processos com múltiplas threads podem realizar mais de 
uma tarefa de cada vez;
• Processos são usados para agrupar recursos; threads
são as entidades escalonadas para execução na CPU
• A CPU alterna entre as threads dando a impressão de que elas 
estão executando em paralelo;
136
Threads
Cada thread tem sua pilha de execução
137
Threads
Itens por Processo Itens por Thread
p Espaço de 
endereçamento
p Variáveis globais
p Arquivos abertos
p Processos filhos
p Alarmes pendentes
p Contador de programa
p Registradores 
(contexto)
p Pilha
p Estado
§ Compartilhamento de recursos;
§ Cooperação para realização de tarefas;
138
Threads
Processo Unix Threads em um processo Unix
139
Threads
• Como cada thread pode ter acesso a qualquer endereço 
de memória dentro do espaço de endereçamento do 
processo, uma thread pode ler, escrever ou apagar a 
pilha de outra thread; 
• Não existe proteção pois:
• É impossível
• Não é necessário pois, diferente dos processos que podem 
pertencem a diferentes usuários, as threads são sempre de um 
mesmo usuário
140
Threads
• Razões para existência de threads:
• Em múltiplas aplicações ocorrem múltiplas atividades “ao mesmo 
tempo”, e algumas dessas atividades podem bloquear de tempos 
em tempos;
• As threads são mais fáceis de gerenciar do que processos, pois 
elas não possuem recursos próprios à o processo é que tem!
• Desempenho: quando há grande quantidade de E/S, as threads
permitem que essas atividades se sobreponham, acelerando a 
aplicação; 
• Paralelismo Real em sistemas com múltiplas CPUs.
141
Threads
• Considere um servidor de arquivos:
• Recebe diversas requisições de leitura e escrita em arquivos e 
envia respostas a essas requisições;
• Para melhorar o desempenho, o servidor mantém uma cache dos 
arquivos mais recentes, lendo da cache e escrevendo na cache
quando possível;
• Quando uma requisição é feita, uma thread é alocada para seu 
processamento. Suponha que essa thread seja bloqueada 
esperando uma transferência de arquivos. Nesse caso, outras 
threads podem continuar atendendo a outras requisições;
142
Threads
• Considere um navegador WEB:
• O servidor deve atender diferentes requisições dos usuários;
• Cada requisição que chega deve ser tratada, no entanto, o servidor 
não deve ficar impedido de receber novas requisições enquanto 
processa uma das requisições;
• Com múltiplas threads, o servidor pode continuar esperando novas 
requisições, enquanto threads são criadas especificamente para 
tratar as requisições;
143
Threads
• Benefícios:
• Capacidade de resposta: aplicações interativas; Ex.: servidor 
WEB;
• Compartilhamento de recursos: mesmo endereçamento; memória, 
recursos;
• Economia: criar e realizar chaveamento de threads é mais barato;
• Utilização de arquiteturas multiprocessador: processamento 
paralelo;
144
Threads
• Tipos de threads:
• Em modo usuário (espaço do usuário): implementadas por 
bibliotecas no espaço do usuário; 
• Criação e escalonamento são realizados sem o conhecimento do 
kernel;
• Sistema Supervisor (run-time system): coleção de procedimentos que 
gerenciam as threads; 
• Tabela de threads para cada processo;
• Cada processo possui sua própria tabela de threads, que armazena 
todas a informações referentes à cada thread relacionada àquele 
processo;
145
Threads em modo usuário
146
Threads em modo usuário
• Tipos de threads: Em modo usuário
• Vantagens:
• Alternância de threads no nível do usuário é mais rápida do que 
alternância no kernel;
• Menos chamadas ao kernel são realizadas;
• Permite que cada processo possa ter seu próprio algoritmo deescalonamento;
• Tem como vantagem poder ser implementado em Sistemas 
Operacionais que não têm threads
• Principal desvantagem:
• Processo inteiro é bloqueado se uma thread realizar uma chamada 
bloqueante ao sistema;
147
Implementação de threads
• Implementação em espaço de usuário:
• Problemas:
• Como permitir chamadas bloqueantes se as chamadas ao sistema são 
bloqueantes e essa chamada irá bloquear todas as threads?
• Mudar a chamada ao sistema para não bloqueante, mas isso implica em 
alterar o SO -> não aconselhável
• Verificar antes se uma determinada chamada irá bloquear a thread e, se for 
bloquear, não a executar, simplesmente mudando de thread
• Se uma thread não liberar a CPU voluntariamente, ela executa o 
quanto quiser
• Uma thread pode não permitir que o processo escalonador do processo tenha 
sua vez
148
Tipos de Threads
• Tipos de threads:
• Em modo kernel: suportadas diretamente pelo SO; 
• Criação, escalonamento e gerenciamento são feitos pelo kernel;
• Tabela de threads e tabela de processos separadas;
• as tabelas de threads possuem as mesmas informações que as tabelas de 
threads em modo usuário, só que agora estão implementadas no kernel;
149
Threads em modo kernel
150
Threads em modo Usuário x 
Threads em modo Kernel
Threads em modo usuário
Threads em modo kernel
151
Threads em modo kernel
• Vantagem:
• Processo inteiro não é bloqueado se uma thread realizar uma 
chamada bloqueante ao sistema;
• Desvantagem:
• Gerenciar threads em modo kernel é mais caro devido às 
chamadas de sistema durante a alternância entre modo usuário e 
modo kernel;
152
Threads
• Estados: executando, pronta, bloqueada;
• Comandos para manipular threads:
• Thread_create;
• Thread_exit;
• Thread_wait;
• Thread_yield (permite que uma thread desista voluntariamente da 
CPU);
153
Implementação
• Java
• Classe Threads
• A própria linguagem fornece suporte para a criação e o 
gerenciamento das threads, as quais são gerenciadas pela JVM e 
não por uma biblioteca do usuário ou do kernel.
• C
• Biblioteca Pthreads
• Padrão POSIX (IEEE 1003.1c) que define uma API para a criação 
e sincronismo de threads; não é uma implementação
154
Threads em Java
Primeira maneira de criação
• Criação da thread:
• Definir uma nova classe derivada da classe Thread
• Redefinir o método run()
• A definição dessa nova classe não cria a nova thread
• A criação é feita através do método start()
• Aloca memória e inicializa uma nova thread na JVM
• Chama o método run(), tornando a thread elegível para ser executada 
pela JVM
155
Threads em Java
Exemplo
class Worker1 extends Thread
{
public void run() {
System.out.println("Eu sou uma thread criada");
}
}
public class First
{
public static void main(String args[]) {
Thread runner = new Worker1();
runner.start();
System.out.println("Eu sou a thread principal");
}
}
156
Threads em Java
Segunda maneira de criação
• Criação da thread
• Definição de uma classe que implemente a interface Runnable.
public interface Runnable
{
public abstract void run();
}
• Definição de um método run()
• A implementação da classe Runnable é semelhante à 
extensão, exceto que “extends Thread” é substituído por 
“implements Runnable”
157
Threads em Java
Exemplo
class Worker2 implements Runnable
{
public void run() {
System.out.println("Eu sou uma thread criada");
}
}
public class Second
{
public static void main(String args[]) {
Thread thrd = new Thread(new Worker2());
thrd.start();
System.out.println("Eu sou a thread principal");
}
}
158
Threads em C
PThreads
Programa principal
pthread_create( &thread1, NULL, proc1, &arg);
pthread_join( thread1, NULL, *status);
thread1
proc1(&arg);
{
return(&status);
}
Thread pode ser desunid (detached)
join não é necessário
Código da thread
159
Threads em C
PThreads
• pthread_create (thread,attr,start_routine,arg)
• thread: identificador único para a nova thread retornada pela função. 
• attr: Um objeto que pode ser usado para definir os atributos (como 
por exemplo, prioridade de escalonamento) da thread. Quando não 
há atributos, define-se como NULL. 
• start_routine: A rotina em C que a thread irá executar quando for 
criada. 
• arg: Um argumento que pode ser passado para a start_routine. Deve 
ser passado por referência com um casting para um ponteiro do tipo 
void. Pode ser usado NULL se nenhum argumento for passado.
160
Threads em C
PThreads
• PThread Join
• A rotina pthread_join() espera pelo término de uma thread específica
for (i = 0; i < n; i++)
pthread_create(&thread[i], NULL, (void *) slave, (void *) &arg);
// código thread mestre
// código thread mestre
for (i = 0; i < n; i++)
pthread_join(thread[i], NULL);
161
Threads em C
PThreads
• Detached Threads (desunidas)
• Pode ser que uma thread não precise saber do término de uma outra por 
ela criada, então não executará a operação de união. Neste caso diz-se 
que a thread criada é detached (desunida da thread pai)
Programa principal
pthread_create();
pthread_create();
Thread
pthread_create();
Thread
Thread Término
Término
Término
162
Threads em C
PThreads
/******************************************************************************
* FILE: hello.c
* DESCRIPTION:
* A "hello world" Pthreads program. Demonstrates thread creation and
* termination.
* AUTHOR: Blaise Barney
* LAST REVISED: 01/29/09
******************************************************************************/
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#define NUM_THREADS 5
void *PrintHello(void *threadid)
{
long tid;
tid = (long)threadid;
printf("Hello World! It's me, thread #%ld!\n", tid);
pthread_exit(NULL);
}
163
Threads em C
PThreads
int main(int argc, char *argv[])
{
pthread_t threads[NUM_THREADS];
int rc;
long t;
for(t=0;t<NUM_THREADS;t++){
printf("In main: creating thread %ld\n", t);
rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t);
if (rc){
printf("ERROR; return code from pthread_create() is %d\n", rc);
exit(-1);
}
}
pthread_exit(NULL);
}
COMUNICAÇÃO E 
SINCRONIZAÇÃO DE 
PROCESSOS
165
Comunicação de Processos
• Processos precisam se comunicar;
• Processos competem por recursos
• Três aspectos importantes:
• Como um processo passa informação para outro processo;
• Como garantir que processos não invadam espaços uns dos 
outros;
• Dependência entre processos: sequência adequada;
166
Comunicação de Processos – Race 
Conditions
• Race Conditions: processos acessam recursos 
compartilhados concorrentemente;
• Recursos: memória, arquivos, impressoras, discos, variáveis;
• Ex.: Impressão: quando um processo deseja imprimir um 
arquivo, ele coloca o arquivo em um local especial 
chamado spooler (tabela). Um outro processo, chamado 
printer spooler, checa se existe algum arquivo a ser 
impresso. Se existe, esse arquivo é impresso e retirado 
do spooler. Imagine dois processos que desejam ao 
mesmo tempo imprimir um arquivo...
167
Comunicação de Processos - Race 
Conditions
abc
prog.c
prog.n
4
5
6
7
.
.
.
.
Processo A
Processo B
in = 7
out = 4 
Próximo slot livre
Próximo arquivo a ser impresso
next_free_slot = 7
Spooler – fila de impressão (slots)
Coloca seu arquivo no slot 7 e 
next_free_slot = 8
next_free_slot = 7
168
Comunicação de Processos - Race 
Conditions
abc
prog.c
prog.n
4
5
6
7
.
.
.
.
Processo A
Processo B
in = 8
out = 4 
Próximo slot livre
Próximo arquivo a ser impresso
checa
next_free_slot = 7
Spooler – fila de impressão (slots)
progB.c
169
abcprog.c
prog.n
4
5
6
7
.
.
.
.
Processo A
Processo B
in = 8
out = 4 
Próximo slot livre
Próximo arquivo a ser impresso
Coloca arquivo a ser 
Impresso no slot 7 e faz
next_free_slot = 8
Spooler – fila de impressão (slots)
progA.c
Processo B não receberá sua impressão!!!!!
Comunicação de Processos - Race 
Conditions
170
Comunicação de Processos – Regiões 
Críticas
• Como solucionar problemas de Race Conditions???
• Proibir que mais de um processo leia ou escreva em recursos 
compartilhados concorrentemente (ao “mesmo tempo”)
• Recursos compartilhados à regiões críticas;
• Exclusão mútua: garantir que um processo não terá acesso à uma 
região crítica quando outro processo está utilizando essa região;
171
Comunicação de Processos – Exclusão 
Mútua
• Quatro condições para uma boa solução:
1. Dois processos não podem estar simultaneamente em regiões 
críticas;
2. Nenhuma restrição deve ser feita com relação à CPU;
3. Processos que não estão em regiões críticas não podem 
bloquear outros processos que desejam utilizar regiões 
críticas;
4. Processos não podem esperar para sempre para acessarem 
regiões críticas;
172
Comunicação de Processos – Exclusão 
Mútua
Processo A
Processo B
Tempo
T1 T2 T3 T4
A entra na 
região crítica
A sai da 
região crítica
B entra na 
região crítica
B sai da 
região crítica
B tenta entrar na 
região crítica - bloqueado
A
173
Soluções
• Exclusão Mútua:
• Espera Ocupada;
• Primitivas Sleep/Wakeup;
• Semáforos;
• Monitores;
• Passagem de Mensagem;
174
Comunicação de Processos – Exclusão 
Mútua
• Espera Ocupada (Busy Waiting): constante checagem por 
algum valor;
• Algumas soluções para Exclusão Mútua com Espera 
Ocupada:
• Desabilitar interrupções;
• Variáveis de Travamento (Lock);
• Estrita Alternância (Strict Alternation);
• Solução de Peterson e Instrução TSL;
175
Comunicação de Processos – Exclusão 
Mútua
• Desabilitar interrupções:
• Processo desabilita todas as suas interrupções ao entrar na 
região crítica e habilita essas interrupções ao sair da região 
crítica;
• Com as interrupções desabilitadas, a CPU não realiza 
chaveamento entre os processos;
• Viola condição 2 (Nenhuma restrição deve ser feita com relação à 
CPU);
• Não é uma solução segura, pois um processo pode não 
habilitar novamente suas interrupções e não ser finalizado;
• Viola condição 4 (Processos não podem esperar para sempre 
para acessarem regiões críticas);
176
Comunicação de Processos – Exclusão 
Mútua
• Variáveis Lock:
• O processo que deseja utilizar uma região crítica atribui um valor a 
uma variável chamada lock;
• Se a variável está com valor 0 (zero) significa que nenhum 
processo está na região crítica; Se a variável está com valor 1 (um) 
significa que existe um processo na região crítica;
• Apresenta o mesmo problema do exemplo do spooler de 
impressão;
177
Comunicação de Processos – Exclusão 
Mútua
• Variáveis Lock - Problema:
• Suponha que um processo A leia a variável lock com valor 0; 
• Antes que o processo A possa alterar a variável para o valor 1, um 
processo B é escalonado e altera o valor de lock para 1;
• Quando o processo A for escalonado novamente, ele altera o valor 
de lock para 1, e ambos os processos estão na região crítica;
• Viola condição 1 (Dois processos não podem estar simultaneamente 
em regiões críticas);
178
Comunicação de Processos – Exclusão 
Mútua
• Variáveis Lock: lock==0;
while(true){
while(lock!=0); //loop
lock=1;
critical_region();
lock=0;
non-critical_region();
}
Processo A
while(true){
while(lock!=0); //loop
lock=1;
critical_region();
lock=0;
non-critical_region();
}
Processo B
179
Comunicação de Processos – Exclusão 
Mútua
• Strict Alternation (Estrita Alternância):
• Fragmentos de programa controlam o acesso 
às regiões críticas;
• Variável turn, inicialmente em 0, estabelece qual processo pode 
entrar na região crítica;
(Processo A)
turn 0
(Processo B)
turn 1
while (TRUE) { 
while (turn!=0); //loop
critical_region();
turn = 1;
noncritical region();} 
while (TRUE){ 
while (turn!=1); //loop
critical_region();
turn = 0;
noncritical region();} 
180
Comunicação de Processos – Exclusão 
Mútua
• Problema do Strict Alternation:
1. Suponha que o Processo B é mais rápido e sai da região 
crítica;
2. Ambos os processos estão fora da região crítica e turn com 
valor 0;
3. O processo A termina antes de executar sua região não crítica 
e retorna ao início do loop; Como o turn está com valor zero, 
o processo A entra novamente na região crítica, enquanto o 
processo B ainda está na região não crítica;
4. Ao sair da região crítica, o processo A atribui o valor 1 à 
variável turn e entra na sua região não crítica;
181
Comunicação de Processos – Exclusão 
Mútua
• Problema do Strict Alternation:
5. Novamente ambos os processos estão na região não crítica e 
a variável turn está com valor 1;
6. Quando o processo A tenta novamente entrar na região 
crítica, não consegue, pois turn ainda está com valor 1;
7. Assim, o processo A fica bloqueado pelo processo B que 
NÃO está na sua região crítica, violando a condição 3;
182
Comunicação de Processos – Exclusão 
Mútua
• Solução de Peterson e Instrução TSL (Test and Set Lock):
• Uma variável (ou programa) é utilizada para bloquear a entrada de 
um processo na região crítica quando um outro processo está na 
região;
• Essa variável é compartilhada pelos processos que concorrem 
pelo uso da região crítica;
• Ambas as soluções possuem fragmentos de programas que 
controlam a entrada e a saída da região crítica; 
183
Comunicação de Processos – Exclusão 
Mútua
• Solução de Peterson
#define FALSE 0
#define TRUE 1
#define N 2
int turn;
int interested[N];
void enter_region(int process)
{
int other;
other = 1 - process;
interested[process] = TRUE;
turn = process;
while (turn == process) && interested[other] == TRUE) ;
}
void leave_region(int process)
{
interested[process] = FALSE;
}
184
Comunicação de Processos – Exclusão 
Mútua
• Instrução TSL: utiliza registradores do hardware;
• TSL RX, LOCK; (lê o conteúdo de lock em RX, e armazena um valor 
diferente de zero (0) em lock – operação indivisível);
• Lock é compartilhada
• Se lock==0, então região crítica “liberada”.
• Se lock<>0, então região crítica “ocupada”.
enter_region:
TSL REGISTER, LOCK | Copia lock para reg. e lock=1
CMP REGISTER, #0 | lock valia zero?
JNE enter_region | Se sim, entra na região crítica,
| Se não, continua no laço
RET | Retorna para o processo chamador
leave_region
MOVE LOCK, #0 | lock=0
RET | Retorna para o processo chamador
185
Soluções
• Exclusão Mútua:
• Espera Ocupada;
• Primitivas Sleep/Wakeup;
• Semáforos;
• Monitores;
• Passagem de Mensagem;
186
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Todas as soluções apresentadas utilizam espera ocupada 
à processos ficam em estado de espera (looping) até que 
possam utilizar a região crítica: 
• Tempo de processamento da CPU;
• Situações inesperadas:
• Processos H (alta prioridade) e L (baixa prioridade)
• L entra na RC
• H começa a executar e quer entrar na RC
187
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Para solucionar esse problema de espera, um par de primitivas Sleep 
e Wakeup é utilizado à BLOQUEIO E DESBLOQUEIO de 
processos.
• A primitiva Sleep é uma chamada de sistema que bloqueia o 
processo que a chamou, ou seja, suspende a execução de tal 
processo até que outroprocesso o “acorde”;
• A primitiva Wakeup é uma chamada de sistema que “acorda” um 
determinado processo;
• Ambas as primitivas possuem dois parâmetros: o processo sendo 
manipulado e um endereço de memória para realizar a 
correspondência entre uma primitiva Sleep com sua correspondente 
Wakeup; 
188
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Problemas que podem ser solucionados com o uso 
dessas primitivas:
• Problema do Produtor/Consumidor (bounded buffer ou buffer
limitado): dois processos compartilham um buffer de tamanho fixo. 
O processo produtor coloca dados no buffer e o processo 
consumidor retira dados do buffer;
• Problemas:
• Produtor deseja colocar dados quando o buffer ainda está cheio;
• Consumidor deseja retirar dados quando o buffer está vazio;
• Solução: colocar os processos para “dormir”, até que eles possam ser 
executados;
189
Comunicação de Processos Sincronização 
Produtor-Consumidor
Proces s o
g ravador
Proces s o
le ito r
dado
Sin cron ização
le i
tu r
a
g ra vação
Bu ffe r
190
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Buffer: variável count controla a quantidade de dados 
presente no buffer. 
• Produtor: 
Se count = valor máximo (buffer cheio)
Então processo produtor é colocado para dormir
Senão produtor coloca dados no buffer e 
incrementa count
191
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Consumidor: 
Se count = 0 (buffer vazio)
Então processo vai “dormir”
Senão retira os dados do buffer e decrementa 
count
192
Comunicação de Processos – Primitivas 
Sleep/Wakeup
# define N 100
int count = 0;
void producer(void)
{
int item;
while (TRUE) {
item = produce_item();
if (count == N) 
sleep();
insert_item(item);
count = count + 1;
if (count == 1) 
wakeup(consumer)
}
}
void consumer(void)
{
int item;
while (TRUE) {
if (count == 0) 
sleep();
item = remove_item();
count = count - 1;
if (count == N - 1) 
wakeup(producer)
consume_item(item);
}
}
193
Comunicação de Processos – Primitivas 
Sleep/Wakeup
# define N 100
int count = 0;
void producer(void)
{
int item;
while (TRUE) {
item = produce_item();
if (count == N) 
sleep();
insert_item(item);
count = count + 1;
if (count == 1) 
wakeup(consumer)
}
}
void consumer(void)
{
int item;
while (TRUE) {
if (count == 0) 
sleep();
item = remove_item();
count = count - 1;
if (count == N - 1) 
wakeup(producer)
consume_item(item);
}
}
Problema: se wakeup chega antes do consumidor dormir
Para 
aqui
194
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Problemas desta solução: Acesso à variável count é 
irrestrita
• O buffer está vazio e o consumidor acabou de checar a variável 
count com valor 0; 
• O escalonador (por meio de uma interrupção) decide que o 
processo produtor será executado; Então o processo produtor 
insere um item no buffer e incrementa a variável count com valor 
1; Imaginando que o processo consumidor está dormindo, o 
processo produtor envia um sinal de wakeup para o consumidor; 
• No entanto, o processo consumidor não está dormindo, e não 
recebe o sinal de wakeup; 
195
Comunicação de Processos – Primitivas 
Sleep/Wakeup
• Assim que o processo consumidor é executado novamente, a 
variável count já tem o valor zero; Nesse instante, o consumidor é 
colocado para dormir, pois acha que não existem informações a 
serem lidas no buffer;
• Assim que o processo produtor acordar, ele insere outro item no 
buffer e volta a dormir. Ambos os processos dormem para 
sempre...
• Solução: bit de controle recebe um valor true quando 
um sinal é enviado para um processo que não está 
dormindo. No entanto, no caso de vários pares de 
processos, vários bits devem ser criados 
sobrecarregando o sistema!!!!
196
Soluções
• Exclusão Mútua:
• Espera Ocupada;
• Primitivas Sleep/Wakeup;
• Semáforos;
• Monitores;
• Passagem de Mensagem;
197
Comunicação de Processos –
Semáforos
• Idealizados por E. W. Dijkstra (1965);
• Variável inteira que armazena o número de sinais 
wakeups enviados;
• Um semáforo pode ter valor 0 quando não há sinal 
armazenado ou um valor positivo referente ao número de 
sinais armazenados;
• Duas primitivas de chamadas de sistema: down (sleep) e 
up (wake);
• Originalmente P (down) e V (up) em holandês;
198
Comunicação de Processos –
Semáforos
• Down: verifica se o valor do semáforo é maior do que 0; 
se for, o semáforo é decrementado; se o valor for 0, o 
processo é colocado para dormir sem completar sua 
operação de down; 
• Todas essas ações são chamadas de ações atômicas;
• Ações atômicas garantem que quando uma operação no 
semáforo está sendo executada, nenhum processo pode acessar o 
semáforo até que a operação seja finalizada ou bloqueada;
199
Comunicação de Processos –
Semáforos
• Up: incrementa o valor do semáforo, fazendo com que 
algum processo que esteja dormindo possa terminar de 
executar sua operação down;
• Semáforo Mutex: garante a exclusão mútua, não 
permitindo que os processos acessem uma região crítica 
ao mesmo tempo
• Também chamado de semáforo binário
200
Comunicação de Processos –
Semáforo Binário
F ila de e spera
de processos
Process o acessa
a reg ião cr í t ica
Process o dese ja en trar
n a região cr ít ica
D OW
N (S= 0)DO
W
N 
(S>
0)
U P (S) - p rocesso sai
da região cr ít ica
L ibe ra proce sso
da f i la de espe ra
Processo é
bloqueado 
sem finalizar
Down(s), pois 
s=0;
Processo executa 
Down(s)
Processo 
finaliza
Down(s), 
pois s>0;
201
Comunicação de Processos –
Semáforos
• Problema produtor/consumidor: resolve o problema de 
perda de sinais enviados;
• Solução utiliza três semáforos:
• Full: conta o número de slots no buffer que estão ocupados; 
iniciado com 0; resolve sincronização;
• Empty: conta o número de slots no buffer que estão vazios; 
iniciado com o número total de slots no buffer; resolve 
sincronização;
• Mutex: garante que os processos produtor e consumidor não 
acessem o buffer ao mesmo tempo; iniciado com 1; também 
chamado de semáforo binário; Permite a exclusão mútua;
202
Comunicação de Processos –
Semáforos
# include “prototypes.h”
# define N 100
typedef int semaphore;
semaphore mutex = 1;
semaphore empty = N;
semaphore full = 0;
void producer (void){
int item;
while (TRUE){
produce_item(&item);
down(&empty);
down(&mutex);
enter_item(item); 
up(&mutex);
up(&full);
}
}
void consumer (void){
int item;
while (TRUE){
down(&full);
down(&mutex);
remove_item(item); 
up(&mutex);
up(&empty);
consume_item(item);
}
}
203
Comunicação de Processos –
Semáforos
• Problema: erro de programação pode gerar um deadlock;
• Suponha que o código seja trocado no processo produtor;
• Se o buffer estiver cheio, o produtor será bloqueado com mutex = 
0; Assim, a próxima vez que o consumidor tentar acessar o buffer, 
ele tenta executar um down sobre o mutex, ficando também 
bloqueado. 
.. ..
down(&empty); down(&mutex);
down(&mutex); down(&empty);
.. ..
204
Soluções
• Exclusão Mútua:
• Espera Ocupada;
• Primitivas Sleep/Wakeup;
• Semáforos;
• Monitores;
• Passagem de Mensagem;
205
Comunicação de Processos –
Monitores
• Idealizado por Hoare (1974) e Brinch Hansen (1975)
• Monitor: primitiva (unidade básica de sincronização) de 
alto nível para sincronizar processos: 
• Conjunto de procedimentos, variáveis e estruturas de dados 
agrupados em um único módulo ou pacote;
• Somente um processo pode estar ativo dentro do monitor 
em um mesmo instante; outros processos ficam 
bloqueados até que possam estar ativos no monitor;
206
Comunicaçãode Processos –
Monitores
monitor example
int i;
condition c;
procedure A();
.
end;
procedure B();
.
end;
end monitor;
Estrutura básica de um Monitor
Dependem da linguagem
de programação à
Compilador é que garante
a exclusão mútua.
§ JAVA
Todos os recursos 
compartilhados entre 
processos devem estar
implementados dentro
do Monitor;
207
Comunicação de Processos –
Monitores
• Execução:
• Chamada a uma rotina do monitor;
• Instruções iniciais à teste para detectar se um outro processo está 
ativo dentro do monitor;
• Se positivo, o processo novo ficará bloqueado até que o outro 
processo deixe o monitor;
• Caso contrário, o processo novo executa as rotinas no monitor;
208
Comunicação de Processos –
Monitores
• Condition Variables (condition): variáveis que indicam 
uma condição; e
• Operações Básicas: WAIT e SIGNAL
• wait (condition) à bloqueia o processo;
• signal (condition)à “acorda” o processo que executou um 
wait na variável condition e foi bloqueado;
209
Comunicação de Processos –
Monitores
• Variáveis condicionais não são contadores, portanto, não 
acumulam sinais;
• Se um sinal é enviado sem ninguém (processo) estar 
esperando, o sinal é perdido;
• Assim, um comando WAIT deve vir antes de um comando 
SIGNAL.
210
Comunicação de Processos –
Monitores
• Como evitar dois processos ativos no monitor ao mesmo 
tempo?
(1) Hoare à colocar o processo mais recente para rodar, 
suspendendo o outro!!! (sinalizar e esperar)
(2) B. Hansen à um processo que executa um SIGNAL
deve deixar o monitor imediatamente;
• O comando SIGNAL deve ser o último de um procedimento do 
monitor;
A condição (2) é mais simples e mais fácil de se 
implementar.
211
Comunicação de Processos –
Monitores
• Devido a exclusão mútua automática dos procedimentos 
do monitor, tem-se:
• o produtor dentro de um procedimento do monitor descobre que o 
buffer está cheio
• produtor termina a operação de WAIT sem se preocupar 
• consumidor só entrará no monitor após produtor dormir 
212
Comunicação de Processos –
Monitores
• Limitações de semáforos e monitores:
• Ambos são boas soluções somente para CPUs com memória 
compartilhada. Não são boas soluções para sistema distribuídos; 
• Nenhuma das soluções provê troca de informações entre processo 
que estão em diferentes máquinas; 
• Monitores dependem de uma linguagem de programação – poucas 
linguagens suportam Monitores;
213
Soluções
• Exclusão Mútua:
• Espera Ocupada;
• Primitivas Sleep/Wakeup;
• Semáforos;
• Monitores;
• Passagem de Mensagem;
214
Comunicação de Processos –
Passagem de Mensagem
• Provê troca de mensagens entre processos rodando em 
máquinas diferentes;
• Utiliza-se de duas primitivas de chamadas de sistema: 
send e receive;
215
Comunicação de Processos –
Passagem de Mensagem
• Podem ser implementadas como procedimentos:
• send (destination,&message);
• receive (source,&message);
• O procedimento send envia para um determinado destino 
uma mensagem, enquanto que o procedimento receive
recebe essa mensagem em uma determinada fonte; Se 
nenhuma mensagem está disponível, o procedimento 
receive é bloqueado até que uma mensagem chegue.
216
Comunicação de Processos –
Passagem de Mensagem
• Problemas desta solução:
• Mensagens são enviadas para/por máquinas conectadas em rede; 
assim mensagens podem se perder ao longo da transmissão;
• Mensagem especial chamada acknowledgement à o 
procedimento receive envia um acknowledgement para o 
procedimento send. Se esse acknowledgement não chega no 
procedimento send, esse procedimento retransmite a mensagem 
já enviada;
217
Comunicação de Processos –
Passagem de Mensagem
• Problemas:
• A mensagem é recebida corretamente, mas o acknowledgement
se perde. 
• Então o receive deve ter uma maneira de saber se uma 
mensagem recebida é uma retransmissão à cada mensagem 
enviada pelo send possui uma identificação – seqüência de 
números; Assim, ao receber uma nova mensagem, o receive
verifica essa identificação, se ela for semelhante a de alguma 
mensagem já recebida, o receive descarta a mensagem!
218
Comunicação de Processos –
Passagem de Mensagem
• Problemas:
• Desempenho: copiar mensagens de um processo para o outro é 
mais lento do que operações com semáforos e monitores;
• Autenticação à Segurança;
219
Comunicação de Processos –
Passagem de Mensagem
220
Comunicação de Processos
Outros mecanismos
• RPC – Remote Procedure Call
• Rotinas que permitem comunicação de processos em diferentes 
máquinas; 
• Chamadas remotas; 
• MPI – Message-passing Interface;
• Sistemas paralelos; 
• RMI Java – Remote Method Invocation
• Permite que um objeto ativo em uma máquina virtual Java possa 
interagir com objetos de outras máquinas virtuais Java, 
independentemente da localização dessas máquinas virtuais; 
• Web Services
• Permite que serviços sejam compartilhados através da Web
221
Comunicação de Processos
Outros mecanismos
• Pipe: 
• Permite a criação de filas de processos;
• ps -ef | grep luciana;
• Saída de um processo é a entrada de outro; 
• Existe enquanto o processo existir;
• Named pipe:
• Extensão de pipe; 
• Continua existindo mesmo depois que o processo terminar;
• Criado com chamadas de sistemas; 
• Socket:
• Par endereço IP e porta utilizado para comunicação entre processos em 
máquinas diferentes;
• Host X (192.168.1.1:1065) Server Y (192.168.1.2:80);
222
Problemas clássicos de comunicação 
entre processos
• Problema do Jantar dos 
Filósofos 
• Cinco filósofos desejam comer 
espaguete; No entanto, para 
poder comer, cada filósofo 
precisa utilizar dois garfo e não 
apenas um. Portanto, os filósofos 
precisam compartilhar o uso do 
garfo de forma sincronizada.
• Os filósofos comem e pensam;
Problemas clássicos de comunicação 
entre processos
• Problema de sincronização 
formulado e resolvido em 
1965 por Dijkstra.
• Problema:
– Cinco filósofos estão 
sentados à mesa.
– Cada filósofo tem um prato 
de espaguete.
– O espaguete é tão 
escorregadio que o filósofo 
precisa de dois garfos para 
comê-lo.
– Entre cada par de pratos 
está um garfo.
224
Problemas clássicos de comunicação 
entre processos
• Problemas que devem ser 
evitados:
• Deadlock – um ou mais 
processos impedidos de 
continuar;
• Starvation – processos 
executam mas não progridem;
4
3
2
1
0
Problemas clássicos de comunicação 
entre processos
• A vida do filósofo consistem em alternar períodos de 
comer e pensar.
• Outras atividades são irrelevantes ao problema.
• Quando um filósofo fica com fome
• Tenta pegar um garfo a direita e a esquerda (um de cada vez em 
qualquer ordem).
• Se conseguir pegar os dois garfos 
• Comerá durante um determinado tempo.
• Colocará os garfos novamente na mesa.
• Continuará a pensar.
Problemas clássicos de comunicação 
entre processos
• Como escrever um programa, para cada filósofo, que 
faça o que deve fazer e nunca trave?
227
Solução 1 para Filósofos 
4
3
2
1
0
Solução 1 para Filósofos 
• A rotina take_fork espera até que o garfo fique disponível 
e então o pega.
• A solução não funciona bem.
• Por que?
229
Solução 1 para Filósofos
• Problema da solução 1:
• Execução do take_fork(i)à Se todos os filósofos pegarem o 
garfo da esquerda, nenhum pega o da direita à Deadlock;
4
3
2
1
0
230
Solução 1 para Filósofos
• Se modificar a solução:
• Pegar o garfo da esquerda
• Verificar se o garfo da direita está disponível. Se não está, devolve o 
da esquerda e começa novamente
• Se tempo para tentativa for fixo à Starvation (Inanição);
• Se tempo for aleatório (abordagem utilizada pela