Sistemas Operacionais 1 - Resumo
Sistemas Operacionais 1 - Resumo
Prof. Ricardo Pinheiro
Prof. Ricardo Pinheiro
10/03/2009
10/03/2009
Sumário
Sumário
1
1 IInnttrroodduuççããoo 33
11..1 1 O O qquue e é é uum m SSiisstteemma a OOppeerraacciioonnaal l ((SSOO))? ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11..11..1 1 FFuunnççõõeess: : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11..11..2 2 OObbjjeettiivvoos s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11..2 2 MMááqquuiinna a dde e NNíívveeiis s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11..3 3 TTiippoos s dde e SSiisstteemmaas s OOppeerraacciioonnaaiis s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11..33..1 1 SSiisstteemmaas s MMoonnoottaarreeffa . a . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11..33..2 2 SSiisstteemmaas s MMuullttiittaarreeffa a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11..33..22..1 1 LLootte e oou u BBaattcch h . . . . . . . 55
11..33..22..2 2 TTeemmppo o CCoommppaarrttiillhhaaddo o ((TTiimmee--SShhaarree) ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11..33..22..3 3 TTeemmppo o RReeaal l ((RReeaall--TTiimmee) ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11..33..3 3 MMuullttiippllaas s UUCCPP´´s s . . . . . . . 66
1. 1.3.3.3.3.1 1 MuMultltipiprorocecessssadadororeses, , ou ou sisiststememas as fofortrtememenente te acacopoplaladodos s . . . . . . . . . . . . . . . . . . . . . . 66
1. 1.3.3.3.3.2 2 MuMultlticicomompuputatadodoreres, s, ou ou sisiststememas as frfracacamamenente te acacopoplaladodos. s. . . . . . . . . . . . . . . . . . . . . . . 77
2 2 CCoonnccoorrrrêênncciiaa 88 22..1 1 IInnttrroodduuççãão o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
22..2 2 IInntteerrrruuppççõõees s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
22..3 3 EExxcceeççõõees s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
22..4 4 CCoonnttrroollaaddoorraas s dde e EE//S S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
22..44..1 1 NNo o iinníícciioo... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
22..44..2 2 EE//S S CCoonnttrroollaadda a ppoor r PPrrooggrraamma a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
22..44..3 3 PPoolllliinng g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
22..44..4 4 EE//S S CCoonnttrroollaadda a ppoor r IInntteerrrruuppççãão o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
22..44..5 5 DDMMA A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
22..44..55..1 1 CCaannaal l DDMMA A . . . . . . . 1111
22..5 5 BBuuffffeerriinng g . . . . . . . 1111
22..6 6 SSppoooolliinng g . . . . . . . 1111
22..7 7 RReeeennttrrâânncciia a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
22..8 8 PPrrootteeççãão o ddo o SSiisstteemma a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122
3 3 EEssttrruuttuurra a ddo o ssiisstteemma a ooppeerraacciioonnaal l 1133 33..1 1 KKeerrnneel . . . . l . . . 1133
33..2 2 BBiibblliiootteeccaas s . . . . . . . 1144
33..22..1 1 CChhaammaaddaas s ddo o ssiisstteemma a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
33..3 3 UUttiilliittáárriioos s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
33..4 4 MMooddoos s dde e aacceesssso o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144 11
SUMÁRIO 2 3.5 Tipos de kernel . . . 15 3.5.1 Monolítico . . . 15 3.5.2 Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.3 Máquina Virtual . . . 15 3.5.4 Microkernel . . . 16 4 Processos e threads 18 4.1 Introdução . . . 18 4.2 Partes do processo . . . 18
4.3 Bloco de controle do processo (PCB) . . . 19
4.4 Estados do processo e mudanças de estado . . . . 19
4.4.1 Mudanças de estado . . . 19
4.5 Criação e eliminação de processos . . . 20
4.6 Concorrência dentro de uma aplicação . . . 20
4.7 Tipos de processo . . . 20
4.8 Sinais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.9 Threads . . . 21
4.9.1 Introdução . . . 21
4.9.2 Ambientes monothread e multithread . . . 21
4.9.2.1 Monothread . . . 21
4.9.2.2 Multithread . . . 22
4.9.3 Formas de implementação . . . 22
4.9.3.1 Threads em Modo Usuário (TMU) . . . 22
4.9.3.2 Threads em Modo Kernel (TMK) . . . 22
4.9.3.3 Threads em Modo Híbrido (TMH) . . . 23
4.9.3.4 Scheduler activations . . . 23
Capítulo 1
Introdução
1.1 O que é um Sistema Operacional (SO)?
• Programa.
• Conjunto de rotinas.
• Executado de forma não-seqüencial. 1.1.1 Funções:
1. Interação homem-máquina. 2. Gerência de recursos.
3. Administração de usuários da máquina (usuários = programas, pessoas). 1.1.2 Objetivos
1. Compartilhar os recursos de forma organizada e protegida. 2. Facilitar o acesso aos recursos.
OBS: Recursos→UCP, memória, HD ....
1.2 Máquina de Níveis
• Computador →hardware e software como uma coisa só para o usuário.
• 6 níveis:
1. São independentes entre si.
2. A passagem por cada uma é obrigatória. 3. Há uma interface entre as camadas.
CAPÍTULO 1. INTRODUÇÃO 4 São eles: Aplicações Linguagem de Montagem Sistema Operacional Linguagem de máquina Microprogramação Hardware (Lógica Digital)
1.3 Tipos de Sistemas Operacionais
Tipos de SO Subtipos Monotarefa ou Monoprogramável –
Multitarefa ou Multiprogramável Batch, ou em lote; Tempo Compartilhado; Tempo Real Múltiplas UCPs Sistemas fortemente e fracamente acoplados • Diferem quanto à:
1. Aplicação
2. Hardware empregado
3. Estrutura interna – complexidade • Desejável: 1. Escalável 2. Rápido 3. Flexível 4. Seguro 5. Tolerante a Falhas 6. Robusto 1.3.1 Sistemas Monotarefa • Um único programa em execução.
• Todos os recursos dedicados a esse programa - desperdício • Estrutura simples
CAPÍTULO 1. INTRODUÇÃO 5 1.3.2 Sistemas Multitarefa
• Vários programas em execução.
• Compartilhamento e gerência dos recursos. • Melhor aproveitamento.
• Estrutura complexa. • Alguns são multiusuário.
1.3.2.1 Lote ou Batch
• 1º SO multitarefa
• fila de submissão de tarefas • tarefas não interativas
• Saída em impressora ou disco
• Podem ser eficientes, como também podem ter tempos de resposta longos • Não são mais usados
1.3.2.2 Tempo Compartilhado (Time-Share)
• Tipo mais comum.
• Conceito defatia de tempo
• Cada tarefa fica em execução até o tempo acabar, dando lugar a outra • Tarefas interativas
Ex: UNIX, WINDOWS
1.3.2.3 Tempo Real (Real-Time)
• Semelhante ao sistema time-share, mas não são iguais. • Tempo de resposta→ dentro de intervalos rígidos.
• Conceito deprioridade→tarefa em execução enquanto não houver outro de mais prioridade do que ele
• Prioridade definida pela aplicação.
CAPÍTULO 1. INTRODUÇÃO 6 1.3.3 Multiplas UCP´s • Processamento paralelo • Conceitos: 1. escalabilidade 2. disponibilidade 3. balanceamento de carga • tendência atual • Problemas: 1. Necessidade de desempenho
2. Problemas mais caros computacionalmente. 3. ”Lei” de Moore – limite físico.
• Solução:
1. uso de arquiteturas com mais de uma UCP
2. software que tire proveito e escalone entre as UCP´s presentes • Caracteristicas desejáveis:
1. escalabilidade – alta 2. disponibilidade – alta
3. balanceamento de carga – justo 4. transparência
5. imagem única do sistema
1.3.3.1 Multiprocessadores, ou sistemas fortemente acoplados
• Memória única.
• Tudo gerênciado por um único SO. • Subdividido em
SMP - Arquitetura simétrica.
NUMA - Acesso Não-Uniforme a Memória.
CAPÍTULO 1. INTRODUÇÃO 7
1.3.3.2 Multicomputadores, ou sistemas fracamente acoplados.
• Memória “espalhada” • Um único SO ou vários
• Cada membro do sistema esta conectado aos outros por um link de dados • Custo de produção mais baixo.
Capítulo 2
Concorrência
2.1 Introdução
• Computador - seu uso é caro computacionalmente
• Objetivo: minimizar o desperdício (tempo que a UCP fica parada) • Momentos de desperdício:
– Frequência da UCP é maior do que a frequência da memória – Velocidade da UCP é muito maior do que a velocidade de E/S. – Baixo uso da UCP em si.
• Solução: Manter a UCP o mais ocupada possível, executando instruções de forma concorrente.
Exemplo: Programa pega 100 registros, ordena e grava o resultado:
Operação Uso Tempo Ler 100 registros: E/S 0,04 s
Ordenar: UCP 0,01 s Gravar o resultado: E/S 0,05 s
Total: 0,10 s.
Total de uso da UCP: 0,01
0,10
s=0,1=10%.
Concorrência - conjunto de técnicas que permite a UCP passar mais tempo ocupada – desempenhando mais
tarefas por instante de tempo (throughput). Abaixo, algumas técnicas de concorrência.
2.2 Interrupções
• Durante a execução, eventos inesperados podem ocorrer→Desvio forçado na execução - interrupção.
Características:
• Evento assíncrono.
CAPÍTULO 2. CONCORRÊNCIA 9 • Evento é externo ao programa.
• Evento gerado por software ou hardware.
• A interrupção é o fundamento básico de concorrência, usado para a sincronização das rotinas do S. O., programas, etc.
• Arquitetura IBM-PC: 16 interrupções de hardware, divididas entre 2 controladoras de interrupção (in-terligadas em cascata):
Exemplo: IRQ1 - relógio (timer); IRQ3 - porta serial 1; IRQ7 - porta paralela; IRQ13 - IDE 1; etc.
• Há a necessidade de termos mecanismos apropriados para cada tipo de interrupção. • Como são tratadas:
– Rotina de tratamento de interrupção – Vetor de interrupção
• Como são assíncronos, podem ocorrer várias vezes, o que atrapalha a execução do programa. Por isso, temos 2 tipos de interrupções:
– Mascaráveis – podem ser ignoradas.
– Não-mascaráveis – não podem ser ignoradas.
• Controlador de pedidos de interrupção - Hardware que gerencia as interrupções.
2.3 Exceções
• Parecidos com as interrupções, mas diferem nos quesitos:
– Evento interno ao programa. – Evento síncrono.
– Tratamento é todo via software.
Exemplo: Divisão por zero, buffer overflow, stack overflow, etc.
• Tratamento feito pelo desenvolvedor, ou pelo hardware (em alguns casos). • Segurança:
– Falhas em programas geram exceções. – Programação segura.
CAPÍTULO 2. CONCORRÊNCIA 10
2.4 Controladoras de E/S
2.4.1 No início...
• UCP fala diretamente com os dispositivos de E/S.
• Problema: E/S é muito mais lento do que a memória ou a UCP. • Introdução do controlador (ou controladora) de E/S:
– Gerência do acesso aos dispositivos de E/S.
– Tira da UCP o trabalho de cuidar dos dispositivos. – Mais eficiente do que a UCP fazer o controle.
• Problema ainda existe →a transferência de dados entre a memória e dispositivo de E/S é feita pela UCP.
• ”Interferência” da UCP.
• Abaixo, algumas técnicas empregadas. 2.4.2 E/S Controlada por Programa
• UCP envia a requisição e move os dados entre a memória e a controladora, aguardando o término da operação.
• UCP fica “presa”, aguardando o término da operação -nada eficiente.
2.4.3 Polling
• UCP envia a requisição, move os dados e é liberada.
• De tempos em tempos, testa para ver se a operação foi concluída. 2.4.4 E/S Controlada por Interrupção
• UCP envia a requisição, move os dados, e é liberada.
• Quando a operação for concluída, a controladora gera uma interrupção, avisando à UCP o término da operação.
• Muito eficiente, mas ainda requer a interferência direta da UCP, fazendo a transferência de dados. 2.4.5 DMA
• Acesso direto a memória
• Controladora fala direto com a memória, sem passar pela UCP - apenas no início e no fim da transferên-cia.
CAPÍTULO 2. CONCORRÊNCIA 11
2.4.5.1 Canal DMA
• Extensão do conceito.
• Diversas “vias” ligando as controladoras da máquina à memória. • Na arquitetura PC há 8 canais
• Chance de uso de buffers para aumentar ainda mais o desempenho.
2.5 Buffering
• Uso de uma área na memória principal, o buffer.
• Velocidade da UCP é muito maior do que a velocidade de E/S.
• Objetivo: acelerar o acesso aos dispositivos de E/S (leitura e gravação). • Manter UCP e E/S ocupados na maior parte do tempo.
• Registro como unidade de transferência.
2.6 Spooling
• Fila de submissão de tarefas - inicialmente em fitas magnéticas. • Arquivo de spool - usado inicialmente em SO´s do tipo batch. • Fila: 1º a entrar , 1º a sair (FIFO).
• Seqüencial - uso de discos com acesso direto – spooling mais eficiente. • Não-sequencial - arquivo no disco.
• Uso no gerenciamento de impressão hoje em dia.
2.7 Reentrância
• Mais comum em sistemas multiusuário.
• Vários usuários usando os mesmos programas.
• Problema: Várias cópias do mesmo programa na memória →desperdício.
• Reentrância: capacidade do código-fonte do programa ser executado e compartilhado entre os usuários do sistema.
• Código executável = código reentrante.
• O código deve ter compilado com essa opção.
CAPÍTULO 2. CONCORRÊNCIA 12
2.8 Proteção do Sistema
• Sistemas mais novos - mais complexos. • Necessidade de aumentar a segurança
• É preciso garantir a confiabilidade e integridade de programas e dados • Situações em que mecanismos de proteção são necessários:
1. áreas reservadas para cada programa e seus dados - evitar a sobreposição dessas áreas. 2. comunicação entre programas de forma sincronizada.
3. Compartilhamento de arquivos no disco 4. Evitar “monopólios” da UCP.
5. Contornar exceções.
Capítulo 3
Estrutura do sistema operacional
Um sistema operacional é composto de três partes: 1. Kernel.
2. Bibliotecas. 3. Utilitários.
3.1 Kernel
• núcleo do sistema.
• Parte central do sistema operacional. • oferecem serviços aos usuários. • execução não-sequencial.
• Principais funções:
1. gerência de processos e threads. 2. gerência de memória.
3. gerência de UCP.
4. gerência de dispositivos de E/S. 5. tratamento de interrupções. 6. tratamento de exceções. 7. suporte a redes.
8. segurança.
9. contabilidade e auditoria do sistema.
• Tipos de kernel: como ele fala com o hardware e software, sua organização interna varia de projeto para projeto.
• Ideal é que seja pequeno, rápido, estável e seguro. 13
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 14
3.2 Bibliotecas
• Conjunto de rotinas usadas por programas. • Fornecem serviços para os programas. • Contém as chamadaa ao sistema. 3.2.1 Chamadas do sistema
• Partes integrantes das bibliotecas.
• Meio organizado e padronizado para acesso ao kernel. • Forma como o kernel pode ser acessado.
• Esconde a complexidade do acesso para o programador. • Programa→System Calls→Kernel→Hardware
• Nomes diferentes para a mesma coisa: 1. Windows: API´s
2. Open VMS: System Services 3. UNIX: System Calls
OBS: No Unix, o que determina se um sistema é “padrão UNIX” ou não é se ele segue a especificação das
System Calls, criada pelo comitê POSIX.
3.3 Utilitários
Programas que auxiliam o funcionamento do sistema operacional.
Exemplos: Compiladores, compactadores, ferramentas de acesso ao disco, etc.
3.4 Modos de acesso
• A UCP tem instruções:
1. privilegiadas - tem acesso a todos os recursos, e mal-usadas, podem comprometer o funcionamento do sistema, gerando instabilidade.
2. não-privilegiadas - não comprometem a estabilidade do sistema operacional. • Modos de acesso - o que são:
1. Solução implementada em hardware, pela UCP. 2. Acesso ou não à instruções privilegiadas.
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 15 4. Hoje em dia, os sistemas são montados de forma que o kernel é o único programa que pode estar
sendo executado no modo privilegiado. • Chaveamento de modos, ou mudança de contexto:
1. Mudança entre os estados do processador, do modo privilegiado para o não-privilegiado, e vice-versa.
2. Custa (pouco) tempo à UCP, mas é desejável que esse tempo seja ainda mais minimizado.
3.5 Tipos de kernel
Antes, dividiremos entre modo usuário (não-privilegiado) e modo kernel (privilegiado). 3.5.1 Monolítico
• Um grande bloco de código, ou dividido em módulos, todos sendo executados no modo kernel. • Estrutura mais simples.
• Desenvolvimento mais simples.
• A manutenção pode ser complexa, se não for um projeto bem-feito e bem amarrado. • Simples na estrutura.
• Rápido.
Ex: MS-DOS, Linux.
3.5.2 Camadas • Níveis sobrepostos.
• Há necessidade de passar por todos os níveis para chegar ao kernel. • Como as camadas são isoladas, facilita a manutenção e a depuração. • Desempenho prejudicado pela estrutura - muito burocrático.
Ex: Open VMS, MULTICS, Windows 2000
3.5.3 Máquina Virtual
• Sistema computacional composto por níveis, onde o nível mais baixo é o hardware.
• Modelo de máquina virtual - nível intermediário entre o hardware e o sistema operacional - gerência de
máquinas virtuais.
• Cada máquina virtual oferece uma cópia virtual do hardware, incluindo os modos de acesso, interrupções, dispositivos de E/S, etc.
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 16 • Cada máquina virtual é independente das demais, contendo seu próprio sistema operacional, seus próprios
usuários e suas próprias aplicações.
• Conceito iniciado no VM/370, baseado no OS/370, da IBM (anos 1960). • Conceito usado também com a linguagem Java - JVM.
• Vantagens:
1. Segurança - Isolamento total das máquinas virtuais.
2. Economia de recursos - mais barato um servidor grande do que vários servidores pequenos.
3. Portabilidade - se o hardware hospedeiro tiver um defeito, basta transferir os arquivos das máquinas virtuais para outro hardware.
• Desvantagens:
1. Complexidade.
2. Sobrecarga - um hipervisor é complexo e consome muitos recursos do hardware hospedeiro. 3.5.4 Microkernel
• Constatação - sistemas atuais ainda são lentos e pesados.
• Microkernel - tornar o núcleo do sistema operacional o menor e mais simples possível. • Disponibilizar os serviços através de processos a serem executados no nível usuário.
• Cada um desses processos servidoresfornecem um recurso específico para o sistema: Gerência de
pro-cessos, gerência de arquivos, escalonamento de propro-cessos, etc.
• A principal função do kernel então é fazer o diálogo entre os diferentes processos servidores.
• Conceito surgido nos anos 1980, com o sistema operacional Mach, desenvolvido na Universidade Carnegie-Mellon.
• O núcleo do Mach fornece 4 serviços, apenas: Gerência de processos, gerência de memória, comunicação por troca de mensagens e operações de E/S, todas em modo usuário.
• Vantagens:
1. Mais seguro: Se um serviço sair do ar, é recolocado facilmente.
2. Apropriado para computação distribuída: Os serviços podem ser remanejados entre as UCPs. 3. Mais flexível.
4. Mais rápido: com o kernel enxuto, menos código a ser executado.
5. Mais facilmente portado para outras arquiteturas: Menos código no kernel, menos dificuldades para reescrever o kernel para outras plataformas.
CAPÍTULO 3. ESTRUTURA DO SISTEMA OPERACIONAL 17 • 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.
Capítulo 4
Processos e threads
4.1 Introdução
• Conceito - base para a implementação de um sistema multiprogramável. • Um programa deve estar sempre associado a um processo.
• Processo - ambiente no qual um programa é executado.
• O processo é colocado em execução e é tirado caso o sistema operacional necessite fazê-lo.
4.2 Partes do processo
• Três partes:
1. Espaço de endereçamento: Área de memória usada pelo processo, onde as instruções e os dados do programa são armaenados para execução.
2. Contexto de hardware: Registradores gerais e específicos da UCP. Quando um processo está em execução, o contexto de hardware guarda os registradores do processador. Quando ele é tirado de execução (mudança de contexto), todos os registradores são salvos no contexto de hardware, para que o processo seja novamente colocado em execução, a partir do ponto onde parou.
3. Contexto de software: Características e limites dos recursos que podem ser alocados pelo processo. Muitas dessas características são determinadas no momento da criação do processo, enquanto outras podem ser alteradas durante a sua existência. São três grupos de informações:
– Identificação:
* Número de identificação do processo (PID). * Nome do usuário que criou o processo (UID). * Grupo do usuário que criou o processo (GID).
– Quotas: Limites de cada recurso do sistema que um prcoesso pode alocar. Exemplos:
* Número máximo de arquivos abertos simultaneamente; * Número máximo de operações de E/S pendentes;
* Tamanho máximo do buffer para operações de E/S; 18
CAPÍTULO 4. PROCESSOS E THREADS 19 * Número máximo de processos, subprocessos e threads que podem ser criados.
– Privilégios: Ações que um processo pode fazer em relação a ele mesmo, aos demais processos e ao
sistema operacional. Exemplos:
* Alterar a prioridade de execução;
* Limites alocados na memória principal e secundária; * Alterar as prioridades de outros processos;
* Desativar o sistema;
* Alterar regras de segurança;
* Criar outros processos privilegiados; * Mudar a configuração do sistema.
4.3 Bloco de controle do processo (PCB)
• O bloco de controle do processo é uma estrutura de dados, mantida pelo sistema operacional, em área reservada, onde todas as informações necessárias para manter o processo em funcionamento são arquiv-adas.
• A gerência de processos é feita por chamadas do sistema.
4.4 Estados do processo e mudanças de estado
• Três estados:
1. Execução: Sendo executado pela UCP.
2. Prontidão (ou pronto): Aguarda a sua vez para ser executado.
3. Espera: Aguarda pelo fim de um evento externo ou por um recurso para continuar o processamento.
Escalonamento: Conjunto de critérios que definem qual processo será colocado em execução primeiro.
4.4.1 Mudanças de estado
• Eventos voluntários ou involuntários podem mudar o estado de um processo:
1. Eventos voluntários: O processo muda por causa de eventos originários de si mesmo. 2. Eventos involuntários: O processos muda por ação do sistema operacional.
• Mudanças:
1. Pronto →execução: Colocado em execução.
2. Execução → espera: Evento externo, como uma operação de E/S, faz o processo ter seu estado
mudado.
3. Espera → pronto: O evento externo foi concluído. Note que não há como passar direto, de espera
CAPÍTULO 4. PROCESSOS E THREADS 20 4. Execução → pronto: O término da fatia de tempo que o processo tem o coloca de volta na fila de
prontidão.
• Processos no estado de espera ou pronto podem estar na memória virtual, por falta de espaço. Logo, a técnica de swapping consiste em mover processos entre as memórias principal e virtual.
4.5 Criação e eliminação de processos
• Dois estados adicionais:
1. Criação→Criou-se a entrada no PCB, mas o processo ainda não foi colocado na lista de prontidão.
É criado por outros processos.
2. Término → O programa foi finalizado, mas o PCB ainda existe. É eliminado por outros processos
ou pelo término nortmal da sua execução.
4.6 Concorrência dentro de uma aplicação
• Três maneiras:
1. Processos independentes: Um processo cria outros, sem vínculos. É a maneira mais simples.
2. Subprocessos: Um processo cria outros, de forma que estão vinculados hierarquicamente: Se o processo-pai é eliminado, os processos-filho também serão. Compartilham quotas.
3. Threads: Ramificações dentro do processo, compartilhando o contexto de software e o espaço de endereçamento. É um modo de gastar menos tempo com criação, escalonamento e eliminação de processos.
4.7 Tipos de processo
1. Foreground: Execução em primeiro plano, interage diretamente com o usuário, com entrada-padrão (teclado) e saída-padrão (monitor).
2. Background: Execução em segundo plano, onde não é preciso interagir diretamente com o usuário. Nesse caso, entrada e saída podem ser arquivos, por exemplo.
3. CPU-Bound: Passa a maior parte da fatia de tempo em estado de execução, ou seja, usando a UCP intensamente.
4. I/O-Bound: Passa a maior parte da fatia de tempo em estado de espera, com muitas operações de E/S.
4.8 Sinais
• Mecanismo que permite ”avisar” processos de eventos gerados pelo sistema operacional ou por outros processos.
CAPÍTULO 4. PROCESSOS E THREADS 21 • Podem ser associados a temporizadores (eventos associados ao tempo).
Exemplos: Notificação de interrupções e exceções, alarmes de tempo, limites de quotas excedidos, etc.
• Eventos que geram sinais - síncronos ou assíncronos.
• Tratamento do sinal - semelhante ao mecanismo de interupções.
• O sinal está para o processo assim como interrupções e exceções estão para o sistema operacional.
4.9 Threads
4.9.1 Introdução
• No início, eram apenas processos.
• Conceito de processo ”leve” (lightweight) →compartilha o espaço de endereçamento.
• Thread - surge primeiro no sistema operacional Mach, da Universidade de Carnegie-Mellon (1980). • Ganho de desempenho e flexibilidade, apesar da complexa implementação.
• Aplicações mais complexas - vários trechos de código em execução paralela - para termos comunicação e sincronização de threads deve-se avaliar desempenho, flexibilidade e custo.
• Apesar da dificuldade em desenvolver, compensa devido aos ganhos obtidos.
Exemplos: Windows 2000 e superiores, Linux, Solaris, etc.
4.9.2 Ambientes monothread e multithread
4.9.2.1 Monothread
• Cada processo tem apenas um thread.
• Concorrência se dá apenas com processos independentes ou subprocessos. • Problema - criar, gerenciar e eliminar processos é computacionalmente caro.
• Compartilhar o espaço de endereçamento é complexo, por conta dos mecanismos empregados. • Processo→Unidade de alocação e de escalonamento.
CAPÍTULO 4. PROCESSOS E THREADS 22
4.9.2.2 Multithread
• Permite que tenhamos aplicações concorrentes de forma mais eficiente:
– Aumenta o desempenho, por dispensar mecanismos de comunicação dentrod o processo.
– Aumenta a eficiência, por termos menos sobrecarga do sistema como um tyodo - menos processos
e mais threads.
• Programas associados a threads.
• Os threads sofrem mudança de estado (pronto, espera e execução), e tem seu próprio bloco de controle (o TCB).
• Processo→Unidade de alocação.
• Thread→Unidade de escalonamento.
• O S. O. vê e escalona os threads de cada processo. 4.9.3 Formas de implementação
• Pacote de threads - Conjunto de rotinas da biblioteca do sistema operacional par aa implementação de threads.
• Falta de padrão em sistemas Unix, até o comitê POSIX liberar uma norma para termos threads, os PThreads.
4.9.3.1 Threads em Modo Usuário (TMU)
• Implementados pela aplicação.
• O sistema operacional não vê os threads, apenas o proceso como um todo. • Podemos ter aplicações multithread em ambientes monothread.
• São rápidos e eficientes, por não fazerem acessos ao kernel, e as mudanças de modo de acesso da UCP (usuário-kernel-usuário).
• Uma chamada a um dispositivo de E/S, feita por um thread, coloca todoo processo em estado de espera.
• O tratamento dos sinais também é complexo, pois o processo terá que tratar o sinal e direcioná-lo ao thread certo.
4.9.3.2 Threads em Modo Kernel (TMK)
• Implementados pelo kernel.
• O sistema operacional gerencia diretamente os threads de um processo.
• Requer mudanças de modo de acesso, logo tem desempenho degradado - bem mais lentos. • Chamadas bloqueantes colocam apenas o thread em estado de espera, não todo o processo.
CAPÍTULO 4. PROCESSOS E THREADS 23
4.9.3.3 Threads em Modo Híbrido (TMH)
• Combina as vantagens dos threads em modo usuário (TMU) e em modo kernel (TMK), mas também as desvantagens.
• Um processo tem vários TMKs, e cadas TMK tem vários TMUs. • O sistema operacional escalona os TMKs, e eles escalonam os TMUs.
• O objetivo é aumentar a flexibilidade, já que apenas os TMKs são escalonados (diminuindo o número de mudanças de modo de acesso), mas também traz os problemas das chamadas bloqueantes, entre outras.
4.9.3.4 Scheduler activations
• Os Threads em Modo Híbrido (TMH) tem problemas devido à falta de comunicação entre os threads. • É desejável unir o melhor das implementações, fugindo dos problemas de cada uma.
• O scheduler activations foi implementado inicialmente na Universidade de Washington, e nessa forma, há uma estrutura de dados que facilita a troca de informações entre o kernel e a biblioteca de threads. Essa estrutura é o scheduler activations.
• O escalonamento é feito pela própria biblioteca, evitando as mudanças de modo de acesso, como por exemplo a ocorrência de uma chamada bloqueante.
