Processos e Threads Capítulo 2 Processos - PUC-Rio

1
2
Capítulo 2
Processos e Threads
2.1 Processos
2.2 Threads
2.3 Comunicação interprocesso
2.4 Problemas clássicos de IPC
2.5 Escalonamento
Processos
O Modelo de Processo
• Considere a multiprogramação de 4 programas:
a) O contador de programa (PC) alternadamente assume
endereços de cada programa
b) Conceitualmente são 4 processos sequenciais
independentes
c) Somente um programa está ativo a cada momento
1

4
Criação de Processos
Um sistema pode executar um conjunto grande de
processos simultâneos/concorrentes.
Principais eventos que levam à criação de
processos:
1. Ao iniciar o sistema operacional (o init)
2. Um processo pai cria um novo processo
(chamda fork())
• Usuário executa comando/ inicia programa através da
shell
• Processo cria um filho para tratar de uma requisição
específica (p.ex. Inet cria processo para tratar
requisição ftp, rsh, etc.)
5
• Início de um programa e em momento prédeterminado
(através do cron daemon)
Término de Processos
Condições que levam ao término de
processos:
1. Saída normal (voluntária)
2. Saída por erro (voluntária)
3. Erro fatal (involuntário)
4. Cancelamento por um outro processo
(involuntário), através de um sinal.
2

6
Hierarquias de Processos
• Processo pai cria um processo filho,
processo filho pode criar seu próprio
processo, etc.
• Forma-se uma hierarquia de processos
– UNIX chama isso de “grupo de processos”
• Windows não possui o conceito de
hierarquia de processos
– Todos os processos são criados no mesmo
nível
Estados de Processos
• Ao longo de sua execução, um processo pode assumir , os
seguintes estados:
– new: processo foi criado.
– running: instruções sendo executadas.
– waiting: Processo aguarda a ocorrência de algum sinal/interrupção.
– ready: Processo aguarda alocação do processador.
– terminated: Processo terminou a sua execução.
7
3

10
Estados de Processos (um pouco
mais proximo da realidade)
Implementação de Processos
A cada processo estão associadas informações sobre o seu
estado de execução (o seu contexto de execução),
Estas ficam armazenadas em uma entrada da Tabela de
Processos (e em Process Control Blocks)
Fig.: Campos da entrada de uma tabela de processos
8
4

Process Control Block (PCB)
P1 P2 P3
PCB 1
PCB 2
PCB 3
Contém informações que são necessárias
quando o processo está em execução.
Em sistemas Unix, o PCB é uma estrutura
no espaço do usuário que é acessada
pelo núclro ( área u)
Para ser capaz de reiniciar um processo
interrompido (ou esperando) o estado
anterior em que deixou a CPU precisa ser
restaurado;
Carrega-se a CPU (e MMU) com as
variáveis do PCB
Troca de contexto
Troca de Contexto
12
13
5

Troca de Contexto
• Consiste de salvar o estado dos recursos em uso
(especialmente CPU) do processo interrompido n
PCB, e carregar a CPU com um novo estado (PC,
registradores, stack pointer, PSW, etc.)
• Esta troca precisa ser:
• Completa e consistente
• Eficiente
• O núcleo não pode ser interrompido durante o
processo
– Precisa-se garantir a atomicidade da operação
• Realizado por um tratador de interrupção genérico,
tratador de interrução de primeiro nível
Tabela de Processos (proc)
Além do PCB, o núcleo gerencia uma tabela de processos, com informações
adicionais por processo;
É uma área no núcleo (vetor de entradas ou lista ligada) com informações
sobre todos os processos, tais como:
– PID
– Endereço do PCB do processo
– Estado do processo
– Ponteiros entre processos nas filas de prontos/bloqueados (usados pelo
escalonador)
– Ponteiros para os processos pai, filho e irmão
– Informação para o tratamento de sinais (máscaras, etc.)
– Informação para gerenciamento de memória,
– Informações estatísticas
– etc.
Obs1: Conjuntamente, o PCB e a entrada na Tabela de Processos contém todas as
informações necessárias para a gerência dos processos
Obs2: No Minix, a entrada TP é uma estrutura em
kernel/proc.c e o array tem tamanho NR_TASKS+NR_PROCS.
14
15
6

Filas dos prontos e de espera por E/S
Tratamento de Interrupções
• Para desviar o controle de execução (para o tratador da
interrpção), o contexto precisa ser trocado.
• Ao receber uma interrupção, o HW empilha novo PC contido
na entrada do vetor de interrupção.
16
17
7

Interrupções vs. Exceções
O conjunto de interrupções depende da arquitetura do
sistema.
A especificação da Intel Architecture IA-32 distingue
dois tipos de sinais que um processador pode
receber:
• Interrupções
– Notificam o processador que um evento ocorreu, e/ou que
o estado de um recurso (p.ex. dispositivo de E/S )mudou
– Gerado por um dispositivo externo ao processador
• Exceção
– Indica a ocorrência de um erro, de hardware ou causado
por uma instrução sendo executada
– Classificados como faults, traps or aborts
Tipos de interrupção reconhecidos pela Intel Architecture IA-32:.
Tipo
Tipos de Interrupções
Descrição para cada tipo
I/O Iniciados pelo HW, notificam o processador de que o estado do
dispositivo de E/S mudou (p.ex. E/S finalizada)
Timer evento periódico para agendamento de ações e/ou monitoramento de
desempenho
Inter-CPU Em sistemas multi-processadores, para comunicação e
sincronização entre processadores
18
19
8

Dispositivo -> I/O Interrupt
Segmentation Fault -> Error
System Call -> Trap
send message -> Trap
Clock Interrupt
Tratamento de Interrupções
Tratador de interrupção específico():
- trata a interrupção (p.ex. Escreve/le dados
de buffer do driver)
- se algum processo foi desbloqueado então
- retorna
Dispatcher, em Assembly:
- desabilita interrupções
- carrega o contexto na CPU &
mapeamento de memória do
processo a ser executado
- habilita interrupções
First Level Int. Handler (FLIH), em Assembly
- desabilita interrupções
- salva contexto em tabela de processos/PCB
- Cria nova pilha temporária no kernel
- carrega no PC o end. do Vetor de Interrupções
- habilita interrupções
Scheduler():
- insere o processo
desbloqueado na fila de
prontos q
- Escolhe próximo processo
- retorna
Tratamento de Interrupções
Esqueleto do que o nível mais baixo do SO faz quando
ocorre uma interrupção
Vetor de Interrupção:
• Localizado em endereço baixo de memória (núcleo)
• Uma entrada para cada tipo de interrupção (trap, clock, E/S)
• Cada entrada contém endereço para um procedimento tratador da interrupção
(tratamento do serviço da interrupção) que identificará de qual dispositivo veio
a interrupção.
20
21
9

Escalonamento
• A cada instante um ou mais processos podem estar
no estado pronto, e.g.:
– Processos do sistema e de usuários
– Processos de vários usuários (sistema time-sharing)
– Mix de processos interativos e batch (simulação, folha de
pagamento)
• Escalonador é responsável por gerenciar a fila de
prontos, e escolher qual dos processos prontos vai
ser o próximo a usar CPU(de acordo com as
prioridades dos processos)
• Também é responsável por aumentar/diminuir a
prioridade dos processos
Escalonamento
• O algoritmo poderá lidar com objetivos conflitantes.
• Por exemplo:
– Garantir justiça (fairness): cada processo ganha fatia igual da CPU
– Aumentar eficiência: manter utilização de CPU alta (próxima a
100%)
– Minimizar tempo de resposta (para processos interativos)
– Minimizar de tempo de retorno (Δt entre início-fim de processos
batch)
– Maximizar taxa de saída: número de processos processados por
unidade de tempo
• Sempre que se beneficia uma classe de processos,
prejudica-se outras classes.
25
26
10

Escalonamento
Tipos de sistemas e objetivos do escalonamento
Escalonamento
• A política de escalonamento deve ser independente do
mecanismo (carregamento da CPU com um contexto)
• Têm parâmetros que precisam ser ajustados para:
• maximizar a “satisfação geral” dos usuários e
• garantir execução mais eficiente das tarefas essenciais ao
sistema
• Principal problema : o comportamento futuro de um processo
não é previsível (fases de uso intensivo da CPU, fases de E/S
frequente)
27
28
11

Escalonamento
1. Escalonamento de longo prazo
– ao ser criado, processo vai para fila dos prontos
– Questão: quando isso é feito e em qual posição ele
entra?
2. “dispatching”
– escalonamento de curto prazo
– Escolhe um dos processos da/s lista/s de prontos para
executar
• Usa-se o termo escolanamento para ambos
Formas de implementar o escalonador
• “embutido” na execução do processo
– Ao final do tratamento da interrupção, o procedimento
para escalonamento é chamado
– Executa como parte do fluxo de controle do processo que
estava em execução
• “autónomo”
– Executa como um processo independente
– Pode estar dedicado a uma CPU em uma arquitetura multicore
– Em máquinas com 1 processador, é executado uma vez a
cada quantum de tempo
– Há uma alternância entre o processo escalonador e os
demais processos
30
31
12

Tipos de Escalonamento
Com relação:
• ao momento da invocação do escalonador:
• preemptivo: a cada clock tick escalonador verifica se
processo corrente já expriou seu quantum de tempo, e se
sim, interrompe-o, e escolhendo outro processo para
executar
• não-preemptivo: escalonador só é chamado quando
processo é bloqueado (chamda de sistema), ou termina
• ao método de seleção do processo mais prioritário:
– Uso da função P = Priority(p)
– Regra de desempate (para processos de mesma prioridade)
• Escolha randômica
• Cronológica (FIFO)
• Cíclica (Round Robin)
Escalonamento por prioridade
• Função de prioridade retorna valor P para processo p:
P = Priority(p)
– Prioridade estática: não muda ao longo da execução de p;
– Prioridade dinâmica: muda em tempo de execução
• Prioridades separam todos processos em níveis:
– Implementado através de filas de pronto multi-nível (e.g.
várias Ready Lists – RLs)
– p @ RL[i] executa antes de q @ RL[j] se i>j
– p, q na mesmo nível são ordenados usando outro critério
32
33
13

Algoritmo geral para um escalonador
preemptivo para multi-processador
Scheduler() {
do { // existe alguma CPU livre
Pegue o processo P mais prioritário de ready_a;
Ache uma CPU livre;
if (cpu != NIL) Aloca_CPU(P,cpu);
} while (cpu != NIL);
do { // todas CPUs estão em uso
Pegue o processo P mais prioritário de ready_a;
Pegue o processo Q em execução de menor prioridade;
if (Priority(P) > Priority(Q)) Preempta(P,Q);
} while (Priority(P) > Priority(Q));
if (self->Status.Type!=’running’) Preempt(P,self);
}
Escalonamento Preemptivo:
como clock ticks são tratados?
• Interrupção clock tick é o 2o. mais prioritário (e ocorre a
cada 10 mseg, (10 -2 segundos)
• Tarefas do tratador:
– Re-arma o clock (se necessário)
– Atualiza estatísticas sobre uso de CPU do processo corrente
– Re-calculo de priordades e tratamento de quantum expirado
– Envia um sinal SIGXCPU para processo corrente, caso seu
quantum tenha expirado
– Atualiza contador time-of-the-day
– Executa funções agendadas do kernel (callouts)
– Trata alarmes
• Algumas das tarefas apenas executadas apenas em major
clock ticks (p.ex. cada 4 ou 10 ticks)
34
35
14

Callouts e Alarmes
callout = função que o kernel deve executar em um
momento futuro, por exemplo:
– retransmissão de pacotes de rede
– Funções de gerenciamento do escalonador ou do
gerente de memória
– Polling de dispositivos que não emitem interrupções
Obs: São mantidos em uma fila ordenada (a qualquer
momento podem surir novos)
alarmes = solicitações “me acorda” feitos por
processos ao kernel, para:
profiling, processos de tempo real, o tempo que
o processo usou em uesr mode.
Parâmetros típicos da Função
Prioridade
• Internos (do sistema)
– Tipo do processo (sistema vs usuário)
– Quantidade de memória necessária
– Tempo total de CPU requisitado
– Tempo de serviço obtido / alcançado
– Tempo total de permanência no sistema
• Externos
– Prazo para término de ação (Deadline)
– Prioridade do usuário: root vs normal (função na
empresa, valor desembolsado)
36
37
15

• Possíveis parâmetros:
Função Prioridade
– a = tempo de serviço alcançado
– r = tempo de permanência no sistema
– t = tempo total de serviço
– d = Periodicidade (para tempo real)
– deadline (explítio ou definido pelo período)
– e = prioridade externa
– Quantidade de memória requisitada (p/ processamento
em lotes)
a
d
r
t
tempo
Algorítmos de escalonamento
Nome, Modo decisão, Priorid., Desempate
FIFO: não-preemptivo P = r randomico
SJF: não-preemptivo P = –t cron./randomico
SRT: preemptivo P = –(t–a) cron./randomico
RR: preemptivo P = 0 cíclico
ML: preemptivo P = e cíclico
não-preemptivo P = e cronológico
• n níveis de prioridade fixa
• nível P é atendido quando as filas n a P+1 estão vazias
SJF= Shortest Job First; SRT = Shortest Remaining Time; RR= RoundRobin;
ML = Multi-level
a = serviço alcançado; r = permanência no sistema, t = tempo total de serviço
e = prioridade externa
38
39
16

First In First Out (FIFO)
Execução por ordem de chegada
Job
A
B
C
Tempo de CPU
8
1
1
A B C
0 8 9 10
Tempo médio de espera (0 + 8 + 9) / 3 = 5.7
Job
A
B
C
Shortest Job First
B C
Tempo de CPU
8
A
0 1 2 10
Tempo médio de espera ótimo:
(0 + 1 + 2) / 3 = 1
1
1
40
41
17

Escalonamento com múltiplas filas (ML)
• Para sistemas com mix de processos interativos e em lote
• Processos são classificados segundo prioridade, e cada
classe tem sua própria fila de prontos.
Priority 1
Priority 2
Priority 3
... ...
Processos sistema
Processos interativos
Processos lote
• Executa todos de prioridade 1, depois 2 …
• Para evitar o problema de inanição (= alguns processos nunca
ganham a vez), pode-se definir períodos de tempo máximos
para cada categoria: por exemplo, 70% para 1, 20% para 2 …
ML – Princípio Geral
• No ML adaptou-se SJF para processos interativos,
considerando o tempo efetivo de CPU entre requisições de E/S
P1
P2
Principal problema: como descobrir qual dos processos prontos
requisitará a CPU por menor período de tempo.
Princípio adotado: Estimar a próxima fatia de tempo necessária,
olhando para o passado.
Exemplo: Seja T0 a estimativa de tempo de uso de CPU e T1 o
tempo de CPU efetivamente utilizado da última vez. Então,
a estimativa para a próxima vez, T2, deveria ser ajustada.
T2 = α*T1 + (1-α)*T0.
Se α > 0.5 dá-se mais importância para o comportamento mais
recente, e α < 0.5 maior importância para o comportamento
mais no passado
42
43
18

Algorítmos de escalonamento
Multiplos níveis com feedback - MLF (Multilevel
with feedback):
– Similar ao ML, mas com uma prioridade que
muda dinamicamente
– Todo processo começa no nível mais alto n
– Cada nível P prescreve um tempo máximo t P
– t P aumenta à medida que P diminui
– geralmente:
t n = Δt (constante)
t P = 2 × t P+1
Filas em múltiplos níveis com feedback
Idéia: Maior prioridade para processos que precisam de fatia
(ou quantum) de tempo (Δt) menor. Se um processo
repetidamente gasta todo seu quantum Δt, passa para
prioridade mais baixa.
Priority 1
Priority 2
Priority 3
Queue
Queue
Queue
1x Δt
2x Δt
4x Δt
... ... ...
• Problema: processos longos, p.ex. que precisam de 100x Δt
– Percorrem 7 prioridades: 1, 2, 4, 8, 16, 32, 64
• Grande vantagem para processos com alta frequência de E/S
44
45
19

Algorítmos de escalonamento
Rate Monotonic (RM):
– Usado para processos periódicos (em sistemas de tempo
real)
– Preemtivo
– Prioridade maior para menor período: P = –d
Earliest Deadline First (EDF):
– Usado para processos periódicos (tempo real)
– Preemtivo
– Prioridade maior para aquele com menor tempo até a
próxima deadline:
• r / d número de períodos completados
• r % d tempo executado no período atual
• d – r % d tempo residual no perídodo atual
• P = –(d – r % d)
• Sistemas em lote
– FIFO, SJF, SRT:
– FIFO é o mais simples
Comparação
– SJF/SRT possuem tempos médios de turnaround (#
processos/tempo) menores
• Sistemas time-sharing
– Tempo de resposta é crítico
– RR puro ou MLF (c/ RR por nível) são apropriados
– A escolha do quantum de tempo q determina o overhead
• Quando q → ∞, RR se aproxima de FIFO
• Quando q → 0, overhead de troca de contexto (TC) → 100%
• Quando q >> overhead de TC, n processos executam desempenho ≈
1/n CPU velocidade
47
48
20

Outras políticas de escalonamento
Escalonamento garantido
• cada um dos n usuários recebe aproximadamente 1/n dos
ciclos de CPU
• Muito simples, e só é feito para processos do usuário (e
não de sistema)
Escalonamento por sorteio (lottery scheduling)
• Sorteio quase aleatório de procesos (todos ou em cada
nível de prioridade)
• Vantagem: simplicidade e distribuição unifore de valores
sorteados geralmente garante igualdade de chances
• Para garantir justiça, impõe-se um limite no número de
vezes que um processo pode ser sorteado em determinado
período
Escalonamento no Minix 3
Algoritmo de escalonamento mul1-­‐nível (16 níveis). Tarefas são escalonadas
sem preempção. Demais processos com Round-­‐Robin Adaptado: se
processo desbloqueado ainda 1ver parte de seu quantum, é posicionado
no começo da fila.
Processos “servidores” tem quantum de tempo maior.
Níveis de prioridade:
– Task_Q
1. Tarefas Sistema e Relógio
2. Tarefa Tty
3. Tarefas Disco, log e mem
4. Servidores RS e PM
5. Servidor FS
– User_Q
6. Processos usuário
7. …
– Idle_Q
16. IDLE
vetores rdy_head[16] e rdy_tail[16], apontam para o começo e final de cada fila
Leitura: seção 2.5.4 no livro do Tanenbaum e Woodhull
59
21

Limitações do Modelo de
Processos
1. Várias aplicações precisam executar
funções inerentemente concorrentes,
compartilhando estruturas de dados
internas. Ex: servidores, monitores de
transacões, protocolos de rede, etc.
2. Não facilita usar o paralelismo de
arquiteturas multi-processadores: aplicação
teria que ser formada por vários processos,
que teriam quecompartilhar dados
Threads
Thread = linha de execução independente dentro de um
mesmo processo
• Multiplas threads são necessárias quando >1 pedidos de E/
S devem ser tratados concorrentemente, e que precisam
compartilhar algumas estruturas de dados (e.g. uma cache
em um servidor de arquivos ou conexões TCP em um
servidor Web;
•
72
73
22

Processos com 1 ou mais threads
Principais Características
• Cada thread tem a sua pilha própria, mas compartinha o
mesmo espaço de endereçamento do processo em que foi
criada;
• Se duas threads executam o mesmo procedimento/método,
cada uma terá a sua própria cópia das variáveis locais;
• As threads podem acessar todas os dados globais do
programa, e o heap (memória alocada dinamicamente)
• Nesse acesso a dados globais (i.e. quando acesso inclui
mais do que uma instrução de máquina), threads precisam
ter acesso em regime de exclusão mútua (p.ex. usando
locks())
74
75
23

76
77
Exemplo de uso de threads
Fig.: Um processador de texto com três threads
Exemplo de uso de Threads
Um servidor web com múltiplas threads
24

Thread Pool
Cada thread executa um procedimento que consome
um request R, processa-o e gera uma resposta 78
Sincronização entre Threads
int pthread_join( pthread_t tid, void* status )
// a thread invocadora é bloqueada até que a thread tid termina
• tid A threadID pela qual deseja-se esperar;
• status O valor de retorno da thread execurando o exit(), será copiada para s
void main() {
pthread_t tid;
int status;
pthread_create(&tid,NULL,thread_main,NULL);
….
pthread_join(tid, (void*) &status);
}
printf(“Return value is: %d\n”, status);
}
void *thread_main( ){
int result;
....
Pthread_exit((void*) result);
80
25

Exemplo de Uso de Threads
#include
#include
#define NUM_THREADS 5
void *PrintHello(void *threadid)
{
printf("\n%d: Hello World!\n", threadid);
/* do other things */
pthread_exit(NULL); /*not necessary*/
}
int main()
{
pthread_t threads[NUM_THREADS];
int t;
for(t=0;t < NUM_THREADS;t++)
{
printf("Creating thread %d\n", t);
pthread_create(&threads[t], NULL, PrintHello, (void *)t);
}
}
for(t=0; t < NUM_THREADS; t++)
pthread_join(threads[t],NULL); /* wait for all the threads to terminate*/
Diagrama de estados de threads
new ThreadExample();
A1vo
Executando
while (…) { … }
New Thread Runnable
Dead Thread
thread.start();
Método run() retorna
Blocked
Object.wait()
Thread.sleep()
blocking IO call
wai1ng on a monitor
81
82
26

Gerenciamento de Threads
Ao contrário de processos, threads compartilham a
mesma região de memória
• Cada thread possui sua própria pilha e contexto de
CPU (conteúdo de PC, SP, registradores, PSW,
etc.)
• Uma tread pode estar nos estados: running,
blocked & ready
Gerenciamento processos vs threads
83
84
27

O Descritor de Thread
• Para cada thread, o kernel (ou biblioteca de threads) mantém a
seguinte informação, que é mantida independente dos descritores
de processos (PCBs)
Contexto:
program counter (PC) /* próxima instrução */
process status word (PSW) /* resultado da operação, ex: carry-bit */
stack pointer (SP) /* pilha de execução do thread */
registers /* conteúdo dos registradores da CPU */
state /* blocked, running, ready */
priority
host_process /* processo hospedeiro ou kernel */
thread_Id /* identificador do thread */
processID /* processo ao qual a thread pertence */
Formas de Implementar Threads
Kernel-level threads (1 para 1):
• thread é a unidade de
escalonamento do núcleo
• A biblioteca de chamadas de
sistema inclui operações para criar/
controlar threads
• Algoritmo de escalonamento é o
implementado pelo núcleo
• Exemplos:
– Windows NT/XP/2000
– Solaris (anterior à vers. 9)
– Linux: LinuxThreads ou
"Native Posix Thread Library
(NPTL)”
– Apple: Multiprocessing
Services
– Unix: NetBSD, FreeBSD
User-level threads (N para 1):
• todas as threads do processo são
mapeadas para única unidade
escalonável do núcleo
• Se qualquer thread do processo fizer
system-call, todo processo é
bloqueado (não aproveita paralelismo
de arquiteturas multi-core)
• políticas de escalonamento são
implementadas na biblioteca de
threads
• Exemplos:
– GNU Portable threads,
– Thread manager (Apple),
– Netscape Portable Runtime,
– State Threads, LWP (SunOS)
– POSIX P-threads, C-threads
85
28

87
88
Threads em Modo Usuário
Biblioteca de threads em nível usuário:
• Escalonamento das threads de acordo com as
necessidades do programa de aplicação. Quando uma
thread requisita E/S, bloqueia todo o processo.
• Exemplos: POSIX P-threads, C-threads
Threads em modo Kernel
(Lightweight Process)
Kernel chaveia entre threads,
independente do processo ao
qual pertencem:
Vantagens:
As proprias funções do kernel
podem ser concorrentes;
Principais problemas:
• Troca de contexto entre threads
precisa considerar proteção de
memória (limites de processo)
• Cada troca de contexto (entre
os LWP) requer um TRAP para
o núcleo (troca modo usuário
para modo supervisor)
Fig.: Threads gerenciadas pelo núcleo
29

Threading híbrido (N para M):
• N theads de um processo são
mapeadas em M threads do núcleo
• Mais difícil de implementar (pois os
escalonadores do modo usuário e do
modo kernel precisam se coordenar)
• troca de contexto pode ser muito
eficiente, pois não requer sempre
uma chamda de sistema
• Exemplos:
– Microsoft Windows7,
– IRIX
– HP-UX
– Tru64 UNIX
– Solaris 8
Tipos de Threads
• Exemplo de “3 para 2”
Mais informações em:
http://www.ibiblio.org/pub/Linux/docs/faqs/Threads-FAQ/html/ThreadLibs.html
90
Implementações Híbridas
Multiplexação de threads de usuário sobre
threads de núcleo
30

Algumas Implementações Posix
Threads (P-threads)
POSIX Threads = modelo de programação, coleção de interfaces que permitem criar,
controlar e efetuar o escalonamento, a comunicação e a sincronização entre threads.
Threads em modo kernel:
• Native POSIX Threading Library (NPTL)
• LinuxThreads (para Linux)
• Win32 Phtreads
Threads em modo usuário:
• FSU Pthreads (SunOS 4.1.x, Solaris 2.x, SCO UNIX, FreeBSD and Linux)
• LPW (SunOS 3/4, mips-ultrix, 386BSD, HP-UX and Linux)
• PCthreads
• PThreads
Mais informações em:
http://www.ibiblio.org/pub/Linux/docs/faqs/Threads-FAQ/html/ThreadLibs.html
Prós e contras
Threads implementados pelo núcleo:
VANTAGENS:
• threads nível usuário não permitem E/S
concorrente se uma thread pede E/S, todo o
processo é bloqueado
DESVANTAGENS:
• Troca de contexto é menos eficiente (requer troca
entre modos: usuário → kernel →usuário)
• Kernel fica mais complexo (precisa implementar
tabelas de threads e de processos)
• Desenvolvedor de aplicação tem menos controle
sobre o escalonamento das threads de seu processo
91
92
31

Outras questões de projeto
Implementação de threads precisa estar coerente com semântica de algumas
system-calls. Por exemplo:
• O que ocorre se processo com >1 threads executa um FORK?, O processo filho
deverá ter o mesmo número de threads do pai?
• E quando a thread do pai está esperando por E/S, e aparece interrupção
sinalizando o término da E/S. As threads no processo pai e no filho recebem o
dado?
• O que acontece se uma thread executa um close(fd) e arquivo fd ainda está em
uso por outra thread?
• Em algumas bibliotecas malloc não é reentrante (possui estado). Portanto, pode
haver problemas se >1 thread executam esta chamada concorrentemente.
• O que acontece se uma thread faz chamda de sistema, e antes que seja capaz de
ler variável global errno, outra thread faz outra chamada a sistema e sobre
escreve errno incial?
Conclusão: quando suporte a threads é incluido no núcleo, a semântica de algumas
chamadas de sistema precisa ser re-definida (e bibliotecas re-implementadas).
Comunicação Inter-processos (IPC)
Existem inúmeras situações em que processos do
sistema (ou do usuário) precisam interagir para
se comunicar ou sincronizar as suas ações, por
exemplo, no acesso compartilhado a dados ou
recursos.
Comunicação Inter-processos envolve:
– Sincronização entre execuções
– Notificações assíncronas
– Troca/compartilhamento de dados
93
95
32

Comunicação Inter-processos (IPC)
Processos e threads são entidades independentes,
que podem ser executados em qualquer ordem.
A ordem de escalonamento é imprevisível.
Precisa-se de mecanismos para evitar problemas
de inconsitência de dados compartilhados
decorrentes da execução concorrente.
recurso
compartilhado
IPC entre processos
Dado
compart.
IPC entre threads
Comunicação e Sincronização entre
Processos: Duas Abordagens
1. Baseada em memória
compartilhada
– Assume que processos/threads
conseguem escrever & ler em
memória compartilhada
– Comunicação é implícita
(através do comparithamento)
mas
– Sincronização precisa ser
explicita
2. Baseada em troca de
mensagens
– Comunication é explicita;
– Sincronização é impícita
process
Dados
thread thread
data
Na comunicação entre processos (Inter-Process Communication - IPC), o
principal problema são as condições de corrida.
process
send(msg) receive(msg)
96
97
33

IPC básico no Unix
• Sinais – notificacões assíncronas entre processos de um
mesmo usuário (e do núcleo para processos)
– Ação default: terminar o processo
– Processo pode definir um tratador de sinal, que reage
independentemente à execução corrente do processo sinalizado
– Limitações: execução tem alto overhead, e sinais não permitem
transferir dados
• Pipes: fluxo de dados unidirecional, entre processos
quaisquer
– Fluxo FIFO, não tipado (fluxo de bytes),
– Ao criar uma pipe, são retornados um descritor de arquivo para
escrita e outro para leitura (usado com read() e write())
– A shell usa pipes para composição de comandos 98
Comunicação Inter-processos (IPC)
Exemplos:
• Processo A e B trocam dados através de um duto (pipe):
processo leitor bloqueia até que o outro processo tenha escrito
algum dado na pipe;
• Dois ou mais processos precisam ler e escrever no mesmo
arquivo;
• Jobs de impressão de dois processos devem ser processados de
forma atômica, para garantir que as saídas (listagem) não saiam
misturadas
• Threads compartilham uma lista (ou vetor) de elementos com
escrita: atualização requer escritas combinadas em vários
endereços de memória
99
34

IPC: Condição de Corrida
Dois processos querem acessar memória compartilhada “ao mesmo
tempo” (e de forma concorrente e imprevisível)
Exemplo:
– processo A lê memória compartilhada“in=7”, e logo depois é interrompido,
– Processo B faz o mesmo e adiciona um novo arquivo no diretório de spool de
impressão
– Quando A re-inicia , sobre-escreve o slot 7 com seu arquivo.
Condição de Corrida
Ocorre sempre que:
• existem dois ou mais processos concorrentes
• Cada processo precisa executar um conjunto de ações
(a1,..aN) que envolvem mais de um dado/recurso
compartilhado, e
• os dados/recursos precisam manter um estado consistente
entre sí;
• antes que complete a execução de todo o conjunto de ações,
um dos processos é interrompido pelo outro
Processo1:
…
A1
A2
A3
w
x
Dado1
Recurso1
w
… Dado2
r
x
Processo2:
…
B1
B2
B3
…
100
101
35

Condição de Corrida
Análogo vale para troca de mensagens (entre processos
clientes e processos servidores)
Exemplos:
1. Para requisitar um serviço, cliente precisa enviar
duas mensagens (1.consulta ao estado, e 2.confirmar
requisição do serviço)
2. Só faz sentido confirmar a requisição, se outro
serviço (complementar, ou anterior) já tiver sido
completado.
client
Ready?
Confirm req.
server
Condição de Corrida
exemplo do dia-a-dia: ligação telefônica
102
103
36

Condição de Corrida
Problemas associados
1. Ausência de atomicidade das ações feitas em dados
compartilhados (requer exclusão mútua ou bloqueio)
2. Processos tentam acessar dados compartilhados
que ainda não estão prontos para serem acessados
3. Operações simultâneas (não previstas) se
bloqueiam mutuamente
Para permitir uma cooperação correta entre
processos é preciso:
• Estabelecer um controle na ordem de execução
• Garantir que algumas execuções ocorram de
forma atômica
Região Crítica
Memória/Recursos compartilhados deveriam ser acessados
em regime de exclusão mútua (um processo de cada vez)
Região crítica (ou Sessão crítica) = parte do programa em
que estão as ações que manipulam os recursos (dados)
compartilhados.
Quatro condições para garantir exclusão mútua:
1. Nunca, dois ou mais processos executam simultaneamente em suas
sessões críticas
2. Não deve haver qualquer suposição sobre velociades e/ou número
de processos
3. Quando executa código fora de uma sessão crítica, um processo
nunca bloqueia outro processo
4. Qualquer processo que entrou em sua sessão crítica, em algum
momento deixa a mesma.
104
105
37

Região Crítica
Para implementar uma região crítica deve haver um
mecanismo/protocolo para garantir a entrada e
saida segura (sincronizada, coordenada) desta
desta parte do código.
Código em um processo:
…
Enter_region; // bloqueia se outro processoe estiver dentro
A1;
A2;
A3;
Exit_region; // sai da região, e libera outros processos esperando
…
Veremos agora algumas possíveis abordagens e
mecanismos
Região Crítica
Exclusão mútua usando Regiões Críticas
106
107
38

Exclusão Mútua com Espera ocupada
(Busy Waiting)
Possibilidades:
• Desabilitar interrupções:
Pode ser usado em modo supervisor, mas não em modo usuário
• Usar uma flag “lock” compartilhada: se lock=0, trocar valor para 1 e processo
entra RC, senão processo espera
Se leitura & atribuição do lock não for atômica, então problema permanece
• Alternância regular de acesso por dois processos (PID= 0; PID= 1)
É um problema, se os processos alternantes requisitam o recurso com
alta frequência
Região Crítica com Espera Ocupada
Solução de Peterson:
• turn e vetor interested[] são variáveis compartilhadas
• Se dois processos PID = {0,1} executam simultaneamente enter_region, o
primeiro valor de turn será sobreescrito (e o processo correspondente vai entrar),
mas interested[first] vai manter o registro do interêsse do segundo processo
108
109
39

Exclusão Mútua com Espera Ocupada
TSL (Test-and-Set-Lock) = instrução de máquina atômica para
leitura de um lock e armazenamento de um valor ≠ 0
Processos que desejam entrar RC executam TSL:
• se lock=0. Entram na RC, senão esperam em loop
Espera Ocupada vs. Bloqueamento
P1
Enter()!
Exit()!
P2
Enter()!
Exit()!
Esp.Oc: para arq. multi-core
P1
Enter()!
Critical region Critical region
Exit()!
kernel
P2
Enter()!
Exit()!
Bloqu:.o núcleo garante atomicidade
110
111
40

Espera Ocupada vs. Bloqueamento
• Solução de Peterson e TSL apresentam o problema
que o loop de espera consome ciclos de
processamento.
• Outro possível Problema: Inversão de prioridades
Se um processo com baixa prioridade estiver na RC,
demorará mais a ser escalonado (e a sair da RC), pois
os processos de alta prioridade que esperam pela RC
estarão em espera ocupada.
A alternativa: Primitivas que bloqueiam o processo e
o fazem esperar por um sinal de outro processo:
Por exemplo:
• sleep :: suspende o processo até que seja acordado
wakeup(PID) :: envia sinal para acordar o processo PID
Problema do Produtor e Consumidor
Sincronização de 2 processos que compartilham um buffer
(um produz itens, o outro consome itens do buffer), e que
usam uma variável compartilhada count para controlar o
fluxo de controle.
• se count=N, produtor deve esperar, e
• se count=0 consumidor deve esperar,
Qualquer processo deve acordar o outro quando estado do
buffer permite prosseguimento do processamento
Produtor
buffer
count
Consumidor
Esse tipo de sincronização está relacionada ao estado do
recurso Sincronização de condição
112
113
41

Problema do Produtor e Consumidor
Condição de corrida: consumidor verifica que count=0, mas antes que execute
sleep, o produtor é escalonado, acrescenta item e executa wakeup. Mas como
consumidor ainda não executou sleep, consumidor ficará bloqueado e sistema
entrará em um impasse.
Semáforos
Em 1965 E.W. Dijkstra (1965) propôs o conceito de
semáforos como mecanismo básico para
sincronização entre processos. A inspiração: sinais
de trens.
114
115
42

Semáforos - Operações
Um semáforo é um objeto do núcleo.
Para cada semáforo s existem duas operações (P/V , Down/Up ou wait/signal):
• Down(&s) :: verifica se pode entrar na Região crítica, e se não puder,
bloqueia;
• Up(&s) :: avisa que deixou região crítica, e causa o desbloqueio de um
úncio processo bloqueado no semáforo;
Semáforo - Implementação
Trata-se de um contador que representa o número de processsos que podem
entrar em uma Região Crítica.
A cada semáforo está associado uma lista de processos bloqueados.
Semântica das operacões:
• Down(s) :: se s=0 processo invocador bloqueia nesta chamada. Se s ≠ 0,
decrementa s e continua execução
• Up(s) :: incrementa s, desbloqueia um dos processos bloqueados (se
houver) e continua execução
p2
up(s)
p6 down(s)
s.val
s.list
p1 p4 p3 p5
Fila de Processos bloqueados
Operações Down e Up geralmente são implementadas como chamadas núcleo,
e durante a sua execução o núcleo desabilita temporariamente as
interrupções (para garantir a atomicidade)
116
117
43

Semáforos - Implementação
Mutex: semáforos binários
Um Mutex, é um semáforo s que pode somente ter dois estados:
Livre e Ocupado (s=1 e s=0, respectivamente)
E as operações recebem outro nome:
• Mutex_lock
• Mutex_unlock
Os mutexes são usados para implementar exclusão mútua
simples, isto é, onde apenas 1 processo pode estar na região
crítica.
118
119
44

Semáforos: Exemplo de Uso
O Problema Produtor-Consumidor usando 1 mutex e 2 semáforos
Monitor – Objeto com sincronizacão
Idéia básica:
Usar o princípio de
encapsulamento de dados
também para a
sincronisação:
• Várias threads podem estar
executando o mesmo
monitor;
• A cada momento, apenas um
procedimento do monitor
pode estar sendo executado;
120
122
45

wait(c)
signal(c)
Monitor
• Monitor é um elemento da
linguagem de programação que
combina o encapsulamento de
dados com o controle para acesso
sincronizado
• Usa-se variáveis de condição
(com operações wait e signal),
quando o procedimento em
execução não consegue completar
e precisa que outro procedimento
seja completado;
• Em Java, tem-se algo similar:
classe com métodos synchronized
Monitor
123
124
46

Monitor: Exemplo de Uso
Resolvendo o problema do produtor-consumidor com monitores
– Exclusão mútua dentro do monitor e controle explícito de sincronizaçnao garante
a coerencia do estado do buffer
– buffer tem N entradas
Principal Diferença entre
Monitores e Semáforos
Monitores só servem para threads:
• Processos não têm acesso a dados
compartilhados (as instâncias de monitor)
Semáforos podem ser usados por processos e
threads
• Semáforos são elementos do núcleo
125
126
47

O Problema dos Leitores e Escritores
Vários leitores podem entrar a RC ao mesmo tempo, mas escritores
precisam executar em exclusão mútua.
r
r
w
w db
• Pode haver até 5
clientes esperando
serviço.
• Se todas cadeiras
ocupadas, cliente
aguarda fora
• Se não há
clientes, barbeiro
tira soneca, até
que chega um
novo cliente
O Problema do Barbeiro
Dorminhoco
127
128
48

O Barbeiro Dorminhoco: Semáforos
Barbeiro sem Dorminhoco:
Monitor
Monitor Barber-shop{
enum{sleep,work} barber;
int waiting =0;
condition x;
Enter(){
if(barber == sleep) barber=work;
else if(waiting

Sincronizacão de Barreira
• Quando todos os processos precisam alcançar um mesmo estado, antes
de prosseguir (exemplo: processamento paralelo “em rodadas” com
troca de informações)
– Processos progridem a taxas distintas
– Todos que chegam a barreira, são bloqueados para esperar pelos
demais
– Quando o retardatário chega, todos são desbloqueados e podem
prosseguir
Sincronização de Barreira
Process {!
! bool last = false;!
! Semaphore barrier;!
! Mutex m;!
! Int count = N!
! Init (&barrier, 0)!
! down(&m)!
! ! count--;!
! ! if (count == 0) last= true;!
! up(&m)!
! if (NOT last) down (&barrier);! // espera pelos demais
processos!
! else for (i=0; i< N; i++) up (&barrier);!
! …!
}
131
132
50

Semáforos
• Todas bibliotecas de threads (ou system
calls) provêm operacões para semáforos:
– sem_t semaphore
– sem_init(&semaphore, 0, some_value);
– sem_down(&semaphore);
– sem_up(&semaphore);
• Em Pthreads usa-se: wait = down; post =
up.
O Jantar dos Filósofos
Sincronização para compartilhamento de recursos 2 a 2
Definição do Problema:
• Filósofos só tem 2 estados:
comem ou pensam;
• Para comer, precisam de dois
garfos, cada qual
compartilhado com os seus
vizinho;
• Só conseguem pegar um
garfo por vez;
Questões globais:
– Como garantir que nenhum
filósofo morre de fome?
– Como evitar o impasse?
133
134
51

Relação entre Jantar dos
Filósofos e S.O.?
Isso é um problema que pode ocorrer em
Sistemas Operacionais?
Considere a situação:
Um processo precisa escrever dados em 2 arquivos ao mesmo tempo, e
cada um desses esses arquivos é compartilhado com outros processos.
Possível solução(?):
Lock fileA !
! Lock fileB !
! Write information to fileA and fileB !
! Release the locks !
Tentativa 1:
O Jantar dos Filósofos
Problema: Cada filósofos tenta pegar o garfo esquerdo, e se
conseguir, espera pela devolução do garfo direito.
E se todos pegarem o esquerdo ao mesmo tempo?
Tentativa 2: Aguarde até obter garfo esquerdo; Se garfo direito
estiver disponível, ok, senão devolve também o garfo esquerdo e
espera.
Qual é o problema agora?
135
136
52

Jantar dos Filósofos
Solução (parte 1)
Jantar dos Filósofos
Solução (parte 2): usar um vetor state[] para verificar o estado dos vizinhos e
dos vizinhos dos vizinhos.
137
138
53

Envio de Mensagens
• É uma forma natural de interação entre processos
• Duas primitivas:
– send(dest, &message) – tam da mensagem fixo ou variável
– receive(fonte, &message) - fonte pode ser ANY
• Requer que processos se conheçam mutuamente
– definem um enlace lógico de comunicação
– Mensagens são tipadas e possuem (header e dados)
• Um enlace pode ser:
– Com processos co-localizados ou remotos
– confiável ou não-confiável
– Ponto-a-ponto ou Ponto-a-multiponto
– Envolve elementos físicos (e.g., memória compartilhada,
barramento, rede)
Envio de Mensagens
• Envio de mensagens é um mecanismo de sincronização
mais genérico, porque:
– Permite também a troca de dados
– É independente se processos compartilham memória ou não.
– Qualquer solução baseada em semáforos pode ser resolvida
por envio de mensagens (considere: Down ≅ receive, Up ≅
send, valor do semáforo = número de mensagens)
• Decisões de projeto do mecanismo:
– Com ou sem bufferização (send assíncrono ou Rendezvous)
– Quando a comunicação é remota (pela rede) mensagens
podem ser perdidas: são necessáriass confirmações,
timeouts e re-transmissões
– Na versão Rendezvous podem ocorrer impasses
139
140
54

Envio de Mensagens
Tipos de Envios de Mensagem
Rendezvous (bloqueante)
producer
kernel
Não-bloquenate
producer
kernel
Entre processos co-localizados
consumer
consumer
Request-Reply síncrono
producer
Request-Reply, não-bloqueante
producer
kernel
kernel
consumer
consumer
141
142
55

Request-Reply Síncrono: possíveis
estados dos processos/threads
Problema do Produtor-Consumidor
com envio de N Mensagens
Idéia: consumidor envia mensagem vazia, e produtor
responde com a mensagem preenchida.
143
144
56

ComunicaçãoRemota entre
processos
• Sockets
• Remote Procedure Calls/ Remote Method
Invocation
Um socket é um ponto
de comunicação de
um processo: um
objeto lógico através
do qual mensagens
podem ser enviadas
e recebidas.
É similar a um
descritor de arquivo
Principal Vantagem:
não ter que conhecer
o PID do processo
Sockets
145
147
57

Sockets
• Concatenação de endereço IP address e porta
• Socket 161.25.19.8:1625 se refere a porta 1625 no host
161.25.19.8
• Localhost: 127.0.0.1
• Uma conexão TCP consiste de um par de sockets
Portas reservadas para serviços Internet
148
149
58

Chamada Remota de Procedimento
(Remote Procedure Call, Remote Method Invocation)
• RPC cria uma abstração de uma chamada de
procedimento entre processos executando em
maquinas uma rede;
• Stubs – proxy no lado do cliente para o
procedimento no lado servidor
• O stub cliente encontra o servidor, estabelece uma
conexão e faz o marshalling dos parámetros
• Stub do lado servidor (skeleton) recebe a
mensagem, desempacota os parâmetros, faz a
chamada do procedimento, empacota o resultado e
envia de volta ao stub cliente.
RPC: Exemplo
150
153
59

RPC
Client Server
Comunicação em Minix
O núcleo implementa os seguintes tipos de comunicação:
– send(dest, &message)
– receive(src, &message)
– send_rec(src_dst, &message)
– notify (dest, &message)
Observações:
• Núcleo copia dados da área do processo fonte (src) para o processo
destinatário (dest), usando CopyMess.
• Existem 6 formatos de mensagem (mess_1, mess_2,…) para diferentes
conjuntos de parâmetros (= union com source, type e tipos de dados),
definidos em kernel/proc.h
• Parâmetros podem ser ponteiros para estruturas de dados do sistema
• Chamadas do sistema, interrupções de HW, do relógio, sinais, etc. todos
são convertidos para envios de mensagens (p.ex. _syscall traduz código
de chamada em mensagem)
154
156
60

IPC no Minix
• Todos os processos e tarefas de Minix interagem através de
envio de mensagens
• Send, receive e send_recv implementam Rendezvous, sempre
entre pares de processos
• Quando remetente e destinatário executaram essas primitivas,
a mensagem é copiada da área do remetente para a área de
memória do destinatário (não é armazenada no núcleo).
• Os campos p_caller_q e p_q_link (nas entradas do dest e src,
na tabela de processos do núcleo) apontam para a entrada dos
processos dos quais está se esperando uma mensagem, ou o
receive, respectivamente.
• Notify é um envio assíncrono e possui prioridade mais alta.
Quando o destinatário não está bloqueado, núcleo guarda
informação de pendência, e quando o mesmo ficar bloqueado,
e recria a mensagem original (BuildMess)
Filas de processos
Todos os processos esperando por enviar uma mensagem
são enfileriados. Exemplo: processos 3 e 4 esperando
para enviar msg ao processo 0;
P_q_link
P_q_link P_q_link
157
158
61

Conclusão
• Processo (thread) são as abstrações de fluxo de
execução independente em um sistema
• Processos possuem um espaço de endereçamento
isolado/protegido dos demais procesos
• Cada processo pode estar executando, pronto, ou
bloqueado;
• O núcleo gerencia a comunicação, a sincronização
e o escalonamento entre processos
• A maioria dos S.O. faz escalonamento preemptivo
com vários níveis de prioridades
163
62