Sistemas Operacionais

Gerência de Processador
Processos
 Conceito fundamental para todos os sistemas operacionais

 Um processo pode ser visto como um programa em execução

Processos
 Exploring /proc File System in Linux
●
https://www.tecmint.com/exploring-proc-file-system-in-linux/

I will give you quick rundown on /proc’s files:

/proc/cmdline – Kernel command line information.

/proc/console – Information about current consoles including tty.
/proc/devices – Device drivers currently configured for the running kernel.
/proc/dma – Info about current DMA channels.
/proc/fb – Framebuffer devices.
/proc/filesystems – Current filesystems supported by the kernel.
/proc/iomem – Current system memory map for devices.
/proc/ioports – Registered port regions for input output communication with device.
/proc/loadavg – System load average.
/proc/locks – Files currently locked by kernel.
/proc/meminfo – Info about system memory (see above example).
/proc/misc – Miscellaneous drivers registered for miscellaneous major device.
/proc/modules – Currently loaded kernel modules.
/proc/mounts – List of all mounts in use by system.
/proc/partitions – Detailed info about partitions available to the system.
/proc/pci – Information about every PCI device.
/proc/stat – Record or various statistics kept from last reboot.
/proc/swap – Information about swap space.
/proc/uptime – Uptime information (in seconds).
/proc/version – Kernel version, gcc version, and Linux distribution installed.
Processos
Possui 3 elementos básicos:

 Contexto de Software - SW – Características do processo como: identificação,

número máximo de arquivos abertos, privilégios, etc

 Contexto de Hardware - HW – Constitui basicamente o conteúdo dos

registradores

 Espaço de endereçamento – É a área de memória pertencente ao processo,

onde estarão armazenados as instruções e os dados para a execução.
Processos
 O SO materializa o processo através do Bloco de Controle de
Processo – PCB p o n te ir o s

Esta d o d o p r o ce sso
 O PCB de todos os processos
ativos residem na memória N o m e d o p r o ce sso
principal em uma área exclusiva Pr io r id a d e d o p ro ce sso
do SO
Re g istr a d o re s

Lim i te s d e m e m ó r ia
Lista d e a r q u ivo s a b e r to s
..
..
..
..
 Estado dos Processos
 Novo: processo está sendo criado
 Execução: as instruções estão sendo executadas
 Espera ou Bloqueado: o processo está esperando algum evento, por exemplo, E/S
 Pronto: o processo está esperando para ser atribuído a algum processador
 Terminado: O processo terminou a execução
Gerenciamento de Processos
Siste m a O p e r a ci o n a l
 Quando um processo está em
execução seu contexto de hardware
é armazenado nos registradores Pr o ce sso A Pr o ce ss o B

e xe cu ta n d o
 Quando o processo A perde a
utilização da CPU para um processo Sa l va r e g istra d o r e s d o
Pr o ce ss o A
B, o sistema deve salvar as
informações do processo A
C a r re g a re g istr a d o re s d o
Pr o ce sso B
 As informações do processo B são
carregadas e xe cu ta n d o

 Posteriormente quando A ganha a Sa l va r e g istra d o r e s d o

Pr o ce sso B
CPU, o estado dos registradores são
restaurados
C a r re g a re g istr a d o re s d o
Pr o ce ss o A

e xe cu ta n d o
 Gerenciamento de Processos
 Sobrecarga associada à mudança de estado realizada pelo SO

 salva contexto do processo

 atualiza bloco de controle do processo (PCB)

 gravação do novo estado (pronto/bloqueado/suspenso...)

 gravação do motivo da mudança de estado

 move o processo (PCB) para a fila apropriada

 escolhe novo processo para execução

 atualiza PCB do novo processo e dados relativos a Memória do Processo - MP

 restaura contexto do novo processo

Gerenciamento de Processos
 Tratamento de interrupção
 Processador fica em modo kernel
 informações de controle salvas no PCB

 despachante pode escalonar outro processo depois do tratamento

 ou, no caso de interrupção por E/S, o SO pode escolher o processo

interrompido para continuar a ser executado e economizar tempo na troca
de contexto

 Muito é investido no hardware para minimizar o custo de tratamento de

interrupção
Gerenciamento de Processos
 Interrupções x Exceções
 Interrupções: eventos causados por dispositivos externos ao processador.

Ex: dispositivo de entrada e saída.

Estes eventos podem ocorrer a qualquer momento.
 Exceções: eventos causados pelo próprio processador.

Causados durante a execução de instruções.

Somente sob certas circunstâncias!

Ex: divisão por zero...
Threads
Em (a), sistemas operacionais tradicionais, cada processo tem
um espaço de endereçamento e um único fluxo de controle

 Em (b), com o conceito de multithread, um processo pode

possuir vários fluxos de controle: threads
Threads
 Atualmente, muitos sistemas operacionais oferecem recursos para que um
processo possua múltiplos fluxos de controle

 O modelo de processo é baseado em dois conceitos independentes:

 agrupamento de recursos
 espaço de endereçamento (código e dados do programa)

 arquivos abertos, processos filhos, etc

 execução
 fluxo de execução (thread de execução)

 Contador de programa, registradores, pilha de execução, etc

 Thread é a entidade básica escalonada pela CPU

Threads
 Processos com múltiplos threads podem realizar mais de uma
tarefa de cada vez
Threads
 Processos com múltiplos threads podem realizar mais de uma
tarefa de cada vez

Multithreaded
Thread Thread Thread
Thread
única TCB TCB TCB

Pilha
PCB do Pilha Pilha Pilha
usuário do do do
PCB usuário usuário usuário
Pilha
Espaço de
do Pilha Pilha Pilha
ender. do
núcleo Espaço de do do do
usuário
ender. do núcleo núcleo núcleo
usuário
Threads
 Com múltiplos threads é possível projetar e implementar aplicações
concorrentes de forma eficiente.
 Um mesmo processo pode ter partes diferentes do seu código sendo executadas
concorrentemente ou em paralelo.

 Os threads compartilham o processador da mesma forma que os

processos e passam pelas mesmas mudanças de estado
 Do mesmo modo, a CPU alterna rapidamente entre os threads

 Algumas CPUs possuem suporte de HW direto para multithread e permitem um

chaveamento mais rápido, isso quer dizer SMT (simultaneous multithreading). O que
costumamos chamar de hyperthreading, mas a palavra hyperthreading é um trademark da
intel.
Threads
 Exemplos
 Navegador Web
 Um thread para exibir imagens ou texto
 Outro thread para recuperar dados da rede

 Processador de textos
 Um thread para exibir gráficos/reformatar um texto
 Outro para ler sequência de teclas do usuário
 Outro para verificação ortográfica e gramatical
 Outro para salvamento automático
Threads
 O espaço de endereçamento dos threads de um processo
é compartilhado
 Um thread pode ler, escrever ou apagar a pilha de execução de outro
thread

 Threads podem compartilhar um conjunto de recursos

 Não há proteção entre threads

 Threads devem cooperar e não competir

 Benefícios no uso de threads
 Capacidade de resposta
 O multithreading de uma aplicação interativa pode permitir que um programa continue
executando mesmo se parte dele estiver bloqueado
 Compartilhamento de recursos
 Os threads compartilham memória e os recursos dos processos aos quais pertencem
 Economia
 Já que os threads compartilham recursos do processo ao qual pertencem é mais
rápido criar e realizar trocas de contexto
 Threads podem se comunicar sem invocar o kernel já que compartilham
memória e arquivos
 no caso de comunicação entre processos, a intervenção do kernel é necessária para
proteção e sincronização
 Threads de usuário
São suportadas acima do kernel e são implementadas por uma biblioteca
de threads no nível do usuário

 A biblioteca fornece suporte à:

 criação e destruição de threads

 envio de mensagens

 escalonamento de threads

 salvamento e recuperação de contexto

 gerenciamento das threads é feito pela aplicação

 sem intervenção do SO
Threads de usuário
 O kernel desconhece a existência de threads:
 As atividades de criação e escalonamento são feitas no espaço do
usuário
 Assim, os threads do usuário são mais rápidos de se gerenciar, pois não é
necessário mudar para o modo kernel

 Pode ser implementado em um SO que não suporte threads

 Desvantagem: Estão em um único processo

 Não aproveita os benefícios do multiprocessamento

 Uma chamada ao sistema bloqueia todas as threads do processo

 Threads de kernel
 Gerenciamento é feito pelo kernel do SO

 Neste caso, o núcleo mantém as informações

de gerenciamento dos processos e threads

 A transferência de controle entre threads de um mesmo

processo requer uma mudança para o modo kernel

 Assim, o gerenciamento de threads de kernel é mais lento do que threads de

usuário
Threads de kernel
 O bloqueio de um thread não bloqueia os outros

 O kernel pode escalonar os threads em diferentes

processadores

 Aproveitam melhor a capacidade de multiprocessamento

 Pode ser adotada uma abordagem híbrida:

 Um processo pode ter vários threads de kernel e um thread de kernel

pode ter vários threads de usuário.
Modelo de multithreading
 Modelo muitos-para-um
– Mapeia muitas threads de usuários em apenas uma thread
de kernel – gerência de threads realizada a nível de usuário
– Não permite múltiplas threads em paralelo
– Exemplo: threads escalonadas em ambiente virtual em SO
nativo.
Modelo de multithreading
 Modelo um-para-um
– Mapeia para cada thread de usuário a uma thread de kernel
– Permite maior concorrência que o Muitos-para-um
• Não bloqueia todas, quando uma solicita I/O
– Permite múltiplas threads em paralelo (multiprocessadores)
– Desvantagem: exige que um thread de usuário crie um
thread de kernel (prejudica desempenho)
Modelo de multithreading
 Modelo muitos-para-muitos
– Mapeia para múltiplos threads de usuário um número menor ou
igual de threads de kernel
– Permite múltiplas threads em paralelo (multiprocessadores)
– Cuidado para não ter muitas threads dentro de uma aplicação
– Modelo híbrido: Muitos para muitos e thread usuário ligadas
diretamente a nível de kernel
 Sistemas Operacionais
Semana 1 – Estrutura, Chamada de Sistemas, Processos e Threads

Prof. Rafael Burlamaqui Amaral

rafael.amaral@inf.ufpel.edu.br