Sincronização e Comunicação entre Processos. Adão de Melo Neto

Transcrição

1 Sincronização e Comunicação entre Processos Adão de Melo Neto 1

2 INTRODUÇÃO Em um sistema multitarefa os processos alternam sua execução segundo critérios de escalonamento estabelecidos pelo sistema operacional. Processos de aplicações concorrentes compartilham diversos recursos do sistema, como arquivos, registros, dispositivos de Entrada/Saída e áreas da memória. 2

3 INTRODUÇÃO O compartilhamento de recursos entre processos pode ocasionar situações indesejáveis, como processamento incorreto de programas Para evitar estas situações indesejáveis, os processos concorrentes devem ter suas execuções sincronizadas, a partir de mecanismos oferecidos pelo sistema operacional. 3

4 ESPECIFICAÇÃO DA CONCORRÊNCIA (FORK E JOIN) A primeira notação para a especificação da concorrência em um programa foram os comandos FORK e JOIN, introduzidos por Conway(1963) e Dennis e Van Horn(1966). 4

5 ESPECIFICAÇÃO DA CONCORRÊNCIA (FORK E JOIN) O programa A começa a ser executado e, ao encontrar o comando FORK, faz com que seja criado outro processo para a execução do programa B, concorrentemente ao programa A O comando JOIN permite que o programa A sincronize-se com o B, ou seja, quando o programa A encontrar o comando JOIN, só continuará a ser processado após o término da execução do programa B. 5

6 PROBLEMA DO COMPARTILHAMENTO DE RECURSOS Os sistemas operacionais multiprogramáveis executam processos concorrentemente. Como os processos concorrentes compartilham recursos do sistema (variável na memória principal ou arquivo no disco, por exemplo), isso pode ocasionar alguns problemas. O programa atualiza o saldo bancário de um cliente após um lançamento de débito ou crédito. O programa lê o registro do cliente no Arquivo Contas, lê o valor a ser depositado ou retirado e, em seguida, atualiza o saldo no Arquivo de contas. leitura atualização 6

7 PROBLEMA DO COMPARTILHAMENTO DE RECURSOS Processo 01 Processo 02 débito crédito Reg_Cliente ARQUIVO CONTAS leitura atualização 7

8 PROBLEMA DO COMPARTILHAMENTO DE RECURSOS Dois PROCESSOS atualizam SALDO de um mesmo CLIENTE O processo 1 (do primeiro funcionário) lê o registro do cliente e debita um valor no saldo do cliente; Antes de gravar o novo saldo do arquivo, o processo 2 (do segundo funcionário) lê o registro do mesmo cliente e credita um valor no saldo do cliente; Independentemente de qual dos processos atualize o saldo primeiro no arquivo, o dado gravado estará inconsistente. leitura atualização 8

9 PROBLEMA DO COMPARTILHAMENTO DE RECURSOS PROCESSO 01 : READ registro de Antônio saldo = 500 PROCESSO 01 : DEBITA 50, = 450 ANTES do PROCESSO 01 fazer um WRITE (Arq_Contas, Reg_Cliente) PROCESSO 02 : READ registro de Antônio saldo = 500 PROCESSO 02 : CREDITA 100, = 600 PROCESSO 01: WRITE (Arq_Contas, Reg_Cliente): saldo = 450 PROCESSO 02: WRITE (Arq_Contas, Reg_Cliente): saldo = 600 (SALDO FINAL ERRADO) Processo 01 Processo 02 débito crédito Reg_Cliente ARQUIVO CONTAS 9

10 EXCLUSÃO MÚTUA (MUTEX) OBJETIVO Evitar que dois ou mais processos acessem um mesmo recurso simultaneamente. MECANISMO Enquanto o processo 01 estiver acessando um determinado recurso e processo 02 deve aguardar o término da utilização do recurso pelo primeiro processo REGIÃO CRÍTICA É a parte do código do programa onde é feito o acesso ao recurso compartilhado é denominada região crítica. EXCLUSÃO MÚTUA É garantir que os processos devem fazer acesso à região crítica de forma sincronizada, ou seja, proibir que dois ou mais processos entrem em suas regiões críticas ao mesmo tempo 10

11 EXCLUSÃO MÚTUA (MUTEX) Recurso compartilhado Região Crítica REGIÃO CRÍTICA É a parte do código do programa onde é feito o acesso ao recurso compartilhado é denominada região crítica. 11

12 PROBLEMA DO COMPARTILHAMENTO DE RECURSOS (RESOLVIDO COM CONTROLE DE ACESSO A REGIÃO CRÍTICA ) PROCESSO 01 : READ registro de Antônio saldo = 500 PROCESSO 01 : DEBITA 50, = 450 PROCESSO 01: WRITE (Arq_Contas, Reg_Cliente): saldo = 450 PROCESSO 02 : READ registro de Antônio saldo = 450 PROCESSO 02 : CREDITA 100, = 550 PROCESSO 02: WRITE (Arq_Contas, Reg_Cliente): saldo = 550 (SALDO FINAL CORRETO) Processo 01 Processo 02 débito crédito Reg_Cliente ARQUIVO CONTAS 12

13 DEADLOCK 13

14 DEADLOCK DEFINIÇÃO É a situação em que um processo aguarda por um recurso que nunca estará disponível ou um evento que nunca ocorrerá. É conseqüência, na maioria das vezes, do compartilhamento de recursos (dispositivos, arquivos e registros,etc) entre processos concorrentes onde a exclusão mútua é exigida. 14

15 PROCESSO 01 ESTÁ COM RECURSO 01 E AGUARDA O RECURSO 02 PROCESSO 02 ESTÁ COM RECURSO 02 E AGUARDA O RECURSO 03 PROCESSO 03 ESTÁ COM RECURSO 03 E AGUARDA O RECURSO 04 PROCESSO 04 ESTÁ COM RECURSO 04 E AGUARDA O RECURSO 01 DEADLOCK É a situação em que um processo aguarda por um recurso que nunca estará disponível ou um evento que nunca ocorrerá. 15

16 DEADLOCK SITUAÇÕES SIMULTÂNEAS PARA QUE OCORRA UM DEADLOCK Exclusão mútua: cada recurso (em uma região crítica) só pode estar alocado a um único processo em um determinado instante; Espera por recurso: um processo, além dos recursos já alocados, pode estar esperando por outros recursos. Não preempção: um recurso não pode ser liberado de um processo só porque outros processos desejam usar o mesmo recurso; Espera circular: um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa. 16

17 DEADLOCK (espera circular) Espera circular: um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa. 17

18 PREVENÇÃO DO DEADLOCK (É preciso garantir que uma das quatro condições necessárias para a sua existência nunca se satisfaça) Exclusão mútua: cada recurso só pode estar alocado a um único processo em um determinado instante; Prevenção: a ausência da exclusão mútua acaba com o problema do deadlock, porém gera os problemas já apresentados com relação ao compartilhamento de recursos. Espera por recurso: um processo, além dos recursos já alocados, pode estar esperando por outros recursos. Prevenção: processos que já possuem recursos garantidos não devem solicitar novos recursos. 18

19 PREVENÇÃO DO DEADLOCK (É preciso garantir que uma das quatro condições necessárias para a sua existência nunca se satisfaça) Não preempção: um recurso não pode ser liberado de um processo só porque outros processos desejam usar o mesmo recurso; Prevenção: permitir que um recurso seja retirado do processo no caso de outro processo necessitar do mesmo recurso. Espera circular: um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa. Prevenção: é forçar o processo a ter apenas um recurso por vez 19

20 CORREÇÃO DEADLOCK SOLUÇÃO 1 eliminar um ou mais processos envolvidos no deadlock e liberar os recursos. A escolha do processo a ser eliminado é feita, normalmente, de forma aleatória ou com base em algum tipo de prioridade MUITO UTILIZADO SOLUÇÃO 2 liberação de apenas alguns recursos alocados aos processos para outros processos, até que o ciclo de espera termine. É necessário que o sistema possa suspender um processo, liberar seus recursos e, após a solução do problema,retornar à execução do processo, sem perder o processamento já realizado. Gera um OVERHEAD muito grande. 20

21 SOLUÇÕES PARA EXCLUSÃO MÚTUA EXCLUSÃO MÚTUA É proibir que dois ou mais processos entrem em suas regiões críticas ao mesmo tempo 21

22 SOLUÇÕES PARA EXCLUSÃO MÚTUA SOLUÇÕES DE HARDWARE Desabilitar Interrupções Instrução test-and-set SOLUÇÕES DE SOFTWARE Algoritmos 1 o, 2 o, 3 o e 4 o propostos para implementar a exclusão mútua Algoritmo de DEKKER Algoritmo de PETTERSON 22

23 SOLUÇÕES PARA EXCLUSÃO MÚTUA Algoritmo de DEKKER Primeira solução de software que garantiu a exclusão mútua entre dois processos sem a incorrência de problemas foi proposta pelo matemático holandês T. Dekker. Tem como base no primeiro e quarto algoritmos. Algoritmo de PETTERSON O algoritmo proposto por G. L. Peterson G. L. Peterson apresenta uma solução para o problema da exclusão mútua entre dois processos que pode ser facilmente generalizada para o caso de N processos. Similar ao terceiro algoritmo 23

24 SINCRONIZAÇÃO CONDICIONAL Situação onde o acesso ao recurso compartilhado exige a sincronização de processos vinculado a uma condição de acesso. EXEMPLO CLÁSSICO Comunicação entre dois processos através de operações de gravação e leitura em um buffer, onde processos geram informações (processos produtores) utilizadas por outros processos (processos consumidores). enquanto um processo grava dados em um buffer, o outro lê os dados, concorrentemente. Os processos devem estar sincronizados a uma variável de condição, de forma que um processo não tente gravar dados em um buffer cheio ou realizar uma leitura em um buffer vazio. 24

25 MECANISMOS (Exclusão Mútua e Sincronização Condicional) SEMÁFOROS Mecanismos para implementação da exclusão mútua e sincronização condicional MONITORES Mecanismos para implementação da exclusão mútua e sincronização condicional TROCA DE MENSAGENS: Mecanismo de sincronização e comunicação entre processos 25

26 PROBLEMA DO PRODUTOR - CONSUMIDOR

27

28

29 Armazena quantidade de espaços preenchidos No BUFFER Armazena quantidade de espaços vazios No BUFFER Se emptycount =0 bloqueia a produção de itens Se fillcount =0 bloqueia a remoção de itens 29

30 NO LINUX, BAIXAR O AQUIVO prod-cons-sem.c IR PARA PASTA /home/aluno/downloads Executar os comandos baixo 30

31 31

32

33

34 ALGUÉM SEMPRE FICAR COM FOME

35

36

37 Bloqueia os filósofos que não pegaram garfos Se mutex =0 já existe alguém na região crítica, bloqueia (não pode entrar)

38 NO LINUX BAIXAR O AQUIVO jantarfilosofos.c IR PARA PASTA /home/aluno/downloads Executar os comandos baixo 38

39 39