processos e threads cap 02 (i unidade)

Sistemas operacionais

modernos Terceira edição

ANDREW S. TANENBAUM

Capítulo 2

Processos e

Threads Adaptado por: Prof. Esp. Rodrigo Ronner [email protected]

http://rodrigoronner.blogspot.com

Processos

Processos

• Processo – entidade dinâmica que consiste num programa em execução, os seus valores correntes, informação de estado e recursos utilizados pelo sistema operativo na gestão da execução do processo;

• Um processo constitui uma atividade. Ele possui programa, entrada, saída e um estado. Um único processador pode ser compartilhado entre os vários processos, com algum algoritmo de escalonamento usado para determinar quando parar o trabalho sobre um processo e servir um outro;

• Todos computadores modernos são capazes de fazer várias coisas ao mesmo tempo;

• Em qualquer sistema multiprogramado, a CPU chaveia de programa para programa, executando cada um deles por dezenas ou centenas de milissegundos;

4

Processos - O Modelo de Processo

• (a) Multiprogramação de quatro programas • (b) Modelo conceitual de 4 processos sequenciais, independentes • (c) Somente um programa está ativo a cada momento

5

Processos – LINUX

• Comandos da shell

• ps – listar processos

• pstree – ver hierarquia dos processos

• top – ver informações adicionais sobre os processos

• kill – enviar sinal a um processo (pode ser um sinal para terminar outro processo)

• Chamadas ao sistema

• fork() – criar um novo processo filho

• exit(.) – terminar processo

• kill(.) – enviar sinal a um outro processo

6

Processos – Windows 2000

• TaskManager

• visualizar os processos que estão a correr

• possibilita ao utilizador a terminação de processos

• Chamadas ao sistema

• CreateProcess(.) – criação de processos

• ExitProcess(.) – saída voluntária

• TerminateProcess(.) – terminação de outro processo

Processos – Criação de Processos

Há quatro eventos principais que fazem com que processos sejam criados:

1. Inicio do sistema

2. Execução de uma chamada ao sistema de criação de processo por um processo em execução

3. Uma requisição do usuário para criar um novo processo

4. Inicio de um Job em lote.

Tecnicamente, em todos estes casos, um novo processo e criado por um processo existente executando uma chamada ao sistema de criação de processo.

Processos – Término de Processos

Depois de criado, um processo começa a executar e faz o seu trabalho. Mais cedo ou mais tarde o processo terminara, normalmente por uma das seguintes razoes:

• Saída normal (voluntária) – Na maioria das vezes os processos terminam porque fizeram o seu trabalho. Outra saída normal e por exemplo quando o utilizador sai do programa como deve ser. (A cruz da janela por exemplo)

• Saída por erro (voluntária) – Quando o processo descobre um erro fatal. O processo emite uma chamada de saída ao sistema.

• Erro fatal (involuntário) – Quando o erro e causado pelo processo, muitas vezes um erro de programa. Exemplos: quando encontra uma divisão por zero, instrução ilegal, etc.

• Cancelamento por um outro processo (involuntário) – Quando um processo executa uma chamada ao sistema dizendo para cancelar algum outro processo. Em linux: kill

9

Processos – Hierarquias de Processos

• Pai cria um processo filho, processo filho pode criar seu próprio

processo;

• Formam uma hierarquia;

• UNIX chama isso de “grupo de processos”.

• Windows não possui o conceito de hierarquia de processos;

• Todos os processos são criados iguais.

10

Processos - Estados de Processos (1)

• Possíveis estados de processos • Em execução (Realmente usando a CPU naquele instante).

• Bloqueado (Incapaz de executar enquanto não ocorrer um evento externo).

• Pronto (executável; temporariamente parado para dar lugar a outro processo).

• Mostradas as transições entre os estados

11


Mostradas as transições entre os estados

• Execução -> Bloqueado: quando um processo descobre que não pode prosseguir passa para o estado de bloqueado:

• Ex: cat teste | grep tree o processo do grep tem de esperar pela saída do processo cat. Se o processo grep tem tempo de CPU e o processo cat ainda não terminou então o grep passa para o estado de bloqueado.

12



• Execução -> Pronto e Pronto -> Execução: transições causadas pelo escalonador de processos, gerenciamento de tempo de CPU, Execução -> Pronto ocorre quando o escalonador de processos decide que o processo em execução já teve o seu tempo de CPU, e Pronto -> Execução ocorre quando já todos os processos estiveram em execução volta novamente para o mesmo.

13



• Bloqueado -> Pronto: ocorre quando o processo que estava no estado bloqueado tem disponível aquilo que estava à espera. Se o CPU estiver livre esse processo passa logo para o estado de Execução, senão fica a aguardar até chegar a sua vez.

Processos: I/O-bound x CPU-bound

•CPU-bound (ligado à CPU)

–Maior parte do tempo em estado de execução

–Ou seja: usando o processador

•I/O-bound (ligado à E/S)

–Maior parte do tempo em estado de bloqueado

–Ou seja: fazendo E/S

•Pode: iniciar CPU-bound e tornar-se I/O-bound (e vice-versa)

•Mais eficiente: revezamento entre CPU-bound e I/O-bound

Gerenciamento de processos

•SO organiza os processos da fila de prontos •Periodicamente o ESCALONADOR de processos: –Escolhe um processo da fila para executar –Critério de escolha pode variar •Alguns critérios usados para escalonamento –Ordem de chegada dos processos –Fatia de tempo demandada pelo processo –Prioridade do processo •Outros nomes para ESCALONADOR/ESCALONAMENTO: –Despachante/despacho –Dispatcher/dispatch •Quando um processo solicita uma operação de E/S –Ele é interrompido e desviado para a fila de bloqueado –Posteriormente, ele retornará para o fim da fila de pronto –Então, será submetido ao critério de escalonamento da fila •Preempção: capacidade do SO de –Interromper um processo a qualquer instante (a seu critério) –Retomar a execução a partir do ponto de interrupção

Bloco de controle do processo (PCB) • Ao criar um processo, o SO cria um BCP (PCB) –É uma tabela com informações relativas ao processo –Reside na RAM enquanto o processo existe –Acesso exclusivo do SO

Bloco de Controle do Processo (ou Descritor do Processo)

Threads

Threads • É o fluxo de controle de um processo. Permitem que múltiplas

execuções ocorram no mesmo ambiente do processo com um grande grau de independência uma da outra.

• Cada thread tem a sua própria pilha. Isso e fácil e perceber porque normalmente cada thread chama procedimentos diferentes… ou se chamam os mesmos o que se vai passar, e diferente para cada thread, então e necessário que cada thread tenha a sua pilha.

• A pilha tem uma estrutura aonde são guardadas as variáveis locais de um procedimento e o endereço de retorno para usa-lo quando o procedimento terminar

Threads – O uso de thread • A principal razão para existirem threads é que em muitas aplicações

ocorrem múltiplas atividades ao mesmo tempo.

• Algumas dessas atividades podem bloquear de tempos em tempos.

• O modelo de programação torna-se mais simples se decompormos uma aplicação em varias threads sequenciais que executam quase em paralelo.

• O paralelismo das threads é o mesmo que existe para os processos mas neste caso as threads de um mesmo processo utilizam todas o mesmo espaço de endereçamento.

• Uma segunda razão para o uso de threads tem a ver com o fato de serem mais fáceis de criar e de destruir do que os processos, pois não tem quaisquer recursos associados a eles.

• Em muitos sistemas criar threads e muito mais rápido que criar processos. Esta propriedade e útil quando o numero de threads necessários se altera dinâmica e rapidamente.

• O desempenho também e uma razão para o uso e threads pois quando existe uma grande quantidade de computação e de E\S, os threads permitem que essas atividades se sobreponham e desse modo aceleram a aplicação.

Aplicações típicas de threads

•Servidor WEB –Cada solicitação de cliente: ativa uma thread (operária) –Processo pai • Atende às novas solicitações que chegam • Despacham threads operárias para execução •Servidor de BD –Cada query de usuário: ativa uma thread (operária) –Processo pai: igual ao exemplo anterior •Processador de texto –Uma rotina básica de captura de teclas (principal) –Com menor prioridade, pode implementar threads para: • Formatar o texto • Fazer revisão ortográfica • Fazer revisão gramatical • Salvar automaticamente o texto (a cada 15 minutos) •Paralelismo: visa aumentar o desempenho (processo e SO)

21

Threads - Uso de Thread (1)

Um processador de texto com três threads

22

Threads - O Modelo de Thread (2)

Cada thread tem sua própria pilha

23

Threads - Uso de Thread (3)

Um servidor web com múltiplos threads

24

Threads – O Modelo de Thread Clássico (1)

(a) Três processos cada um com um thread (b) Um processo com três threads

25

Threads – O Modelo de Thread Clássico (2)

• Items compartilhados por todos os threads em um processo;

• Itens privativos de cada thread;

26

Threads – Implementação de threads no espaço do usuário Sucintamente: O usuário cria um processo e depois é o próprio processo que gerência as suas threads. O processo tem uma tabela de threads, gerida por um sistema supervisor, para manter o controle sobre elas, tabela essa que é em tudo parecida a tabela de processos do núcleo.

Vantagens: quando uma thread decide parar de executar, a informação da thread e guardada na tabela de threads e o escalonador de threads pode ser chamado pela parada daquela thread e selecionar outra thread para executar.

A vantagem disto é que é mais eficiente, o escalonador de threads e o guardar a informação da thread na tabela assim do que fazer uma chamada ao núcleo.

Outra vantagem e cada processo pode ter o seu algoritmo de escalonamento personalizado.

27

Threads – Implementação de threads de núcleo • Contrariamente a implementação de threads de usuário, a

implementação de threads de núcleo funciona com o núcleo a gerir as duas tabelas, a de processos bem como a das threads.

• Esta tabela das threads acompanha todas as threads do sistema, enquanto que na implementação de threads de usuário cada tabela de threads apenas gerência as threads correspondentes a um processo.

28

Threads – Implementação de threads no espaço do usuário

Threads – Implementações Híbridas

Comunicação entre processos

31

Comunicação entre processos

Frequentemente processos precisam se comunicar com outros.

Há três tópicos em relação a isso:

• O primeiro é como um processo passa informação para um outro;

• O Segundo é como garantir que dois ou mais processos não entrem em conflito;

• O Terceiro é como como uma sequência adequada quando existirem dependências: se o processo A produz dados e o processo B os imprime, B deve esperar até que A produza alguns dados antes de iniciar a impressão.

33

Comunicação entre processos: Condições de Disputa

(ou de Corrida)

• Situações que 2 ou mais processos estão lendo ou escrevendo algum dado compartilhado e cujo resultado final depende da ordem de execução;

• Pergunta: isso quer dizer que uma máquina no Brasil e outra no Japão, cada uma com processos que se comunicam, nunca terão Condições de Disputa?

34

Ex.: Vaga em avião

1. Operador OP1 (no Brasil) lê Cadeira1 vaga;

2. Operador OP2 (no Japão) lê Cadeira1 vaga;

3. Operador OP1 compra Cadeira1;

4. Operador OP2 compra Cadeira1;


(ou de Corrida)

35

Exemplo:

As vagas 0 a 3 estão vazias (os arquivos já foram impressos) e as vagas 4 e 6 estão preenchidas (com os nomes dos arquivos na fila de impressão). Mais ou menos simultaneamente, os processos A e B decidem que querem colocar um arquivo na fila de impressão.

• O processo A lê in e armazena o valor 7, na variável local;

• Logo em seguida ocorre interrupção do relógio e a CPU decide que o Processo A já executou suficiente. Então chaveia para processo B;

• Este também lê entrada e obtém igualmente um 7;

• Ele do mesmo modo, armazena o 7 em sua variável local;

• Neste instante, ambos os processos pensam que a próxima vaga disponível é a 7;

• O processo B prossegue sua execução. Ele armazena o nome de seu arquivo na vaga 7 e atualiza in com 8. A partir disso, ele fará outras coisas.

• Eventualmente, o processo A executa novamente a partir de onde parou.

• Verifica próxima vaga livre, encontra lá um 7 e escreve seu nome de arquivo na vaga 7.

• Apagando o nome que o processo B acabou de por lá.

• Então ele calcula próxima vaga livre + 1, que é 8, e põe 8 em in.

O que aconteceu com processo B???


(ou de Corrida)

36

Comunicação entre processos:

Condição de Corrida

Dois processos querem ter acesso simultaneamente à memória compartilhada

37


Regiões críticas

As regiões criticas são a resposta para evitar o problema das condições de disputa. Dando-lhe outro nome: exclusão-mutua é um modo de assegurar que outros processos sejam impedidos de usar uma variável ou arquivo que já esteja a ser utilizado por um outro processo. Região critica e aquela parte do programa em que existe acesso à memoria partilhada. Para chegar a uma boa solução de evitar as condições de disputa precisamos satisfazer quatro soluções. 1. Nunca dois processos podem estar simultaneamente nas suas regiões criticas; 2. Nada pode ser afirmado sobre a velocidade ou sobre o número de CPU’s ; 3. Nenhum processo executando fora da sua região critica pode bloquear outros processos; 4. Nenhum processo deve esperar eternamente para entrar na sua região critica;

38


Exclusão mútua com espera ociosa

• Varias soluções para o problema das regiões critica. Mas todas elas com o problema da espera ociosa. Quer isto dizer que quando um processo entra na sua região critica nenhum outro pode entrar nessa mesma região invadindo-a e causando danos.

• A espera ociosa faz com que os processos que querem entrar na região estejam constantemente a perguntar se podem (averiguar uma variável por exemplo) e isto não e muito bom pois assim consome o tempo de CPU desnecessário.

Propostas para obtenção de exclusão mútua: Soluções de hardware –Desabilitar interrupções –Instrução test-and-set (atomicidade): “variável global” na RAM •Soluções de software –Algoritmo de Dekker –Algoritmo de Peterson –Algoritmo de Lamport



Solução de Peterson



56

Semáforos •Conceito proposto por E. W. Dijkstra (déiquistra), em 1965

•Mecanismo de sincronização não estruturado e complexo

•Permite implementar, de forma simples:

–Exclusão mútua e

–Sincronização entre processos

•Um dos principais mecanismos utilizados

–Nos projetos de SO e nas aplicações concorrentes

–Nas linguagens de programação (rotinas para semáforos)

•Um semáforo (S) é:

–Uma variável especial protegida pelo SO (não-negativa)

–Manipulada por duas instruções atômicas (indivisíveis)

• Down (decremento) e

• Up (incremento)

•Se S=zero e Down: thread fica em espera (não ocupada)

•Instruções são implementadas no hardware do processador

•Semáforo está associado a um recurso e pode ser

–binário (ou Mutex): {0;1}

–contador: qq valor inteiro, não-negativo

Semáforos

• Pipes

Exemplo: ps awux | grep httpd

Exemplos Semafóros

60

Monitores • Conceito proposto por Brinch Hansen, em 1972

• Mecanismos de sincronização de alto nível que tentam tornar mais fácil o desenvolvimento e correção de programas concorrentes;

• Conjunto de procedimentos, variáveis e estrutura de dados definidos dentro de um módulo;

• Somente um processo pode estar executando um dos procedimentos do monitor em um determinado instante;

• Implementação da exclusão mútua nos monitores é realizada pelo compilador;

• WAIT – Faz um processo entrar em estado de espera quando uma variável de condição (estrutura de dados tipo fila) está impedindo a liberação para outros processo;

• SIGNAL – Liberação do recurso pelo processo que o alocou.

Monitores

62

Troca de Mensagens

• Mecanismo de comunicação e sincronização entre processos.

• SEND – Envia uma mensagem a um processo receptor

• SEND (Receptor, Mensagem)

• RECEIVE – Recebe uma mensagem de um processo transmissor

• RECEIVE (Emissor, Mensagem)

• Não ocorre exclusão mútua;

• Uma mensagem só pode ser lida apos Ter sido enviada;

• Pode ocorrer perda de mensagens ACK (acknowledgement) – enviada pelo processo receptor para informar o recebimento da mensagem;

• Se o emissor não receber um ACK em determinado tempo, reenvia a mensagem;

• Endereçamento direto – só permite a comunicação entre dois processos;

• Endereçamento indireto – utiliza uma área compartilhada (buffer conhecido como mailbox) onde as mensagens podem ser colocadas pelo emissor e retiradas pelo receptor.

63

• Quando os dois processo se comunicam de forma síncrona, dizemos que eles fazem um rendezvous (encontro, em francês “randevu”). Um processo envia uma mensagem e fica esperando até que o receptor leia a mensagem.

• Um receptor tenta receber uma mensagem e fica esperando até que o

processo transmissor grave alguma mensagem.

• Dispensa necessidade de buffers.

• A necessidade de espera reduz o grau de concorrência.

• Comunicação assíncrona: O transmissor não aguarda o recebimento da mensagem.

• O receptor não aguarda o envio de uma mensagem.

• Necessita de buffers

• Maior paralelismo na execução dos processos em relação a síncrona.

Troca de Mensagens

64

Escalonamento

• Quando um computador é multiprogramado, ele muitas vezes tem varias processos que competem pela CPU ao mesmo tempo;

• Está situação ocorre sempre que dois processos estão no estado de pronto;

• Se apenas um CPU se encontra disponível, devera ser feita uma escolha de qual processo executara primeiro;

• A parte do sistema operacional que faz essa escolha é chamada de escalonador e o algoritmo que ele usa é o algoritmo de escalonamento.

65

Escalonamento

• Quando um computador é multiprogramado, ele muitas vezes tem varias processos que competem pela CPU ao mesmo tempo;

• Está situação ocorre sempre que dois processos estão no estado de pronto;

• Se apenas um CPU se encontra disponível, devera ser feita uma escolha de qual processo executara primeiro;

• A parte do sistema operacional que faz essa escolha é chamada de escalonador e o algoritmo que ele usa é o algoritmo de escalonamento.

66

Escalonamento: Objetivos do escalonador

67

• Filósofos comem/pensam

• Cada um precisa de 2 garfos para comer

• Cada filósofo tenta pegar um garfo por vez

• Como prevenir deadlock?

Problemas Clássicos de IPC: Jantar dos Filósofos

68

• Jantar dos filósofos não é um problema estudado apenas porque é legal;

• Ele representa a necessidade de alocar vários recursos para diferentes processos, sem que ocorra deadlock e/ou starvation;

• Ou mesmo de alocar recursos escassos;


69

Uma solução errada para o problema do jantar dos filósofos - deadlock


70

• Que tal pegarmos um garfo e se não conseguir pegar o outro, devolver o garfo e esperar um tempo fixo?

• Problema de espera de tempo:

• pode chegar a um caso de Starvation;

• E se esperar por um tempo aleatório?

• A maioria das vezes dá certo, mas nem sempre;

• Essas solução é usada em rede local Ethernet quando há colisão de pacotes;

• Mas há problemas que exigem que a solução dê certo sempre: controle de segurança de uma usina nuclear;


71

Jantar dos filósofos

• Que tal usarmos semáforo?

• Vamos proteger as 5 chamadas após o think() com um semáforo;

• O que acontece?

72

Jantar dos Filósofos

Uma solução para o problema do jantar dos filósofos (parte 1)

73

Jantar dos Filósofos

Uma solução para o problema do jantar dos filósofos (parte 2)

processos e threads cap 02 (i unidade)

Documents