1 / 23

Faculdade Pernambucana - FAPE

Faculdade Pernambucana - FAPE. Sistemas Operacionais. Prof. Flávio Gonçalves da Rocha. Processos. Um processo é uma abstração de um programa em execução. O compartilhamento de tempo/multitarefa possibilita a ilusão de paralelismo para sistemas com 1 processador

gyan
Télécharger la présentation

Faculdade Pernambucana - FAPE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Faculdade Pernambucana - FAPE Sistemas Operacionais Prof. Flávio Gonçalves da Rocha

  2. Processos • Um processo é uma abstração de um programa em execução. • O compartilhamento de tempo/multitarefa possibilita a ilusão de paralelismo para sistemas com 1 processador • Para simplificar o monitoramento de atividades paralelas foi desenvolvido um modelo (processos sequenciais) que torna o paralelismo mais fácil de tratar

  3. Processos Modelo de Processo • Todo o software executável é organizado em um número de processos seqüenciais ou somente processos • Um processo inclui os valores atuais do controlador de programa, registradores e variáveis.

  4. Processos Um contador de Programa A Quatro Contadores de Programa Processo B D C B A Alternância de Processo C A C B D D Tempo • Multiprogramação de quatro programas. (b) Modelo conceitual de quatro • processos seqüenciais independentes. (c) Só um programa está ativo em • qualquer dado instante

  5. Processos Modelo de Processo • A diferença entre um processo e um programa é sutil: • Um programa é um algoritmo expresso em alguma notação conveniente • Um processo é um tipo de atividade que faz com que o programa seja executado usando para isso, entrada e saída. Além disso, ele apresenta um estado

  6. Processos Hierarquia de Processos • Na maioria dos SOs é preciso dispor de alguma maneira de criar e de destruir processos conforme necessário. • Os processos precisam de uma maneira de criar outros processos (chamadas de sistemas por exemplo) • Cada processo tem um pai, mas zero, um dois ou mais filhos formando assim, uma hierarquia de processos

  7. Processos Estado de um Processo • Os processos, apesar de independentes, freqüentemente precisam interagir entre si • Ex: um processo gera uma saída que outro processo utiliza como entrada • Um processo pode ficar bloqueado se a entrada e saída que estiver esperando ainda não estiver disponível

  8. Processos Estado de um Processo • Os três estados que um processo pode estar são: 1. Executando – Utilizando a cpu 2. Pronto – Temporariamente pára para permitir que outro processo execute 3. Bloqueado – Incapaz de executar até que algum evento externo aconteça (chamada BLOCK)

  9. Processos 1. O processo bloqueia a entrada 2. O agendador seleciona outro processo 3. O agendador seleciona esse processo 4. A entrada torna-se disponível Executando 1 2 3 Pronto Bloqueado 4 Um processo pode estar em execução,em estado bloqueado ou pronto

  10. Processos Estado de um Processo • Usando o modelo de processos, torna-se muito mais fácil pensar no que está ocorrendo dentro do sistema • O nível mais baixo do SO é o agendador de processos com uma variedade de processos nele ... 0 1 N-2 N-1 Agendador dfs A camada mais baixa de um SO estruturado em processos gerencia interrupções e agendamento

  11. Processos Comunicação entre Processos • Freqüentemente os processos precisam se comunicar com outros processo • Ex: dir | find “05/05/2008” • Na comunicação entre processo, resumidamente, há três questões básicas: • Como um processo pode passar informações para outro

  12. Processos Comunicação entre Processos • Como certificar-se que dois ou mais processos não interfiram um com outro quando envolvidos em atividades críticas • Sequenciamento adequado quando estão presentes dependências entre processos

  13. Comunicação entre Processos Condições de Corrida • Processos que trabalham juntos podem compartilhar área comum de armazenamento (memória principal ou arquivo) onde cada um pode ler ou gravar Diretório De Spooler Se dois processos quiserem colocar simultaneamente um arquivo na fila de impressão pode haver problema. ... Processo A 4 5 6 7 Out = 4 ... Processo B In = 7 fg

  14. Comunicação entre Processos Condições de corrida • Situações em que dois ou mais processos estão lendo ou gravando alguns dados compartilhados, e o resultado final depende de quem executa precisamente quando, são chamadas condições de corrida (race conditions).

  15. Comunicação entre Processos Sessões Críticas • Como evitamos condições de corrida? • A chave é encontrar alguma maneira de proibir que mais de um processo leia e grave os dados compartilhados ao mesmo tempo, ou seja, precisamos de uma exclusão mútua. • A parte do programa em que a memória compartilhada é acessada é chamada região crítica ou seção crítica

  16. Comunicação entre Processos Sessões Críticas • Para se ter processos paralelos que cooperam correta e efetivamente, utilizando dados compartilhados, precisamos sustentar quatro condições: • Nenhum dos dois processos pode estar simultaneamente dentro de suas regiões críticas • Nenhuma suposição pode ser feita sobre as velocidades ou sobre o número de CPUs

  17. Comunicação entre Processos Sessões Críticas • Nenhum processo que executa fora de sua região crítica pode bloquear outro processo • Nenhum processo deve ter de esperar eternamente para entrar em sua região crítica

  18. Comunicação entre Processos • Exclusão Mútua com Espera Ativa/Ocupada • Algumas propostas para obter exclusão mútua • Desativando as interrupções • Variáveis de bloqueio • Alternância estrita • A solução de Peterson

  19. Comunicação entre Processos Desativando as interrupções • A solução mais simples é fazer cada processo desativar todas as interrupções imediatamente depois de ele entrar em sua região crítica e reativá-las imediatamente depois de ele sair dela • Nenhuma interrupção ou relógio pode ocorrer • A CPU não alternará de um processo para outro • Problemas: • E se o processo do usuário não ativar novamente as interrupções lkjo

  20. Comunicação entre Processos Desativando as interrupções • Em sistemas multiprocessados apenas uma CPU é afetada. A outra pode continuar gerando interrupções para a área compartilhada. • É conveniente para o kernel desativar interrupções por um determinado período enquanto está atualizando variáveis ou listas • Para o SO é útil desativar instruções, mas não é apropriado como um mecanismo geral de exclusão mútua para processos de usuário.

  21. Comunicação entre Processos Variáveis de Bloqueio • Solução de software • Utilizar uma variável (bloqueio) para controlar o acesso à região crítica. • Se a variável for 0 significa que o processo pode entrar na região crítica, se for 1 não • Problema: • Mesmo problema do spooler. A variável pode ser lida simultaneamente

  22. Comunicação entre Processos Alternância Estrita • Testar continuamente o valor de uma variável até que algum valor apareça é chamado espera ativa • Desperdício de CPU • Interessante quando a expectativa for de uma espera curta Processo 0 Processo 1 While( TRUE ) { while ( turn != 0 ); critical_region( ); turn = 1; noncritical_region( ); } While( TRUE ) { while ( turn != 1 ); critical_region( ); turn = 0; noncritical_region( ); } jkjçl

  23. Comunicação entre Processos Alternância Estrita • A utilização de turn não é uma boa idéia quando um dos processos é muito mais lento do que o outro. • Um processo na região não crítica poderá bloquear outro (viola a condição 3).

More Related