sistemas - cloud object storage · a programação concorrente é um paradigma de programação...

Sistemas

Operacionais Sincronização e

Comunicação entre

Processos – parte 1/2

Sumário

1. Introdução

2. Programação Concorrente

3. Aplicações Concorrentes

4. Especificação de Concorrência

5. Compartilhamento de Recursos

6. Exclusão Mútua

1. Soluções de Hardware

2. Soluções de Software

7. Sincronização Condicional

8. Semáforos

9. Monitores

1. Exclusão Mútua

2. Sincronização Condicional

10. Troca de Mensagens

11. Deadlock

1. Prevenção

2. Detecção e Correção

1. Introdução

É natural que processos de uma aplicação concorrente compartilhem recursos do sistema, como por exemplo:

Arquivos ou registros.

Dispositivos de E/S.

Áreas de memória.

O compartilhamento de recursos entre processos realizado de maneira inadequada pode ocasionar problemas:

Programas complexos, ineficientes e ineficazes.

Inconsistência de dados.

Comprometimento da execução de aplicações ou do sistema.

Como evitar os problemas decorrentes do compartilhamento de recursos entre os processos de uma aplicação concorrente?

2. Programação Concorrente

A programação concorrente é um paradigma de programação para a construção de programas que fazem uso da execução concorrente (podendo ser simultânea) de várias tarefas computacionais interativas.

Como programação paralela e programação concorrente se relacionam?

A programação paralela utiliza de múltiplos processadores para executar partes diferentes de um mesmo programa simultaneamente.

Quais são as principais questões discutidas durante o desenvolvimento de sistemas concorrentes?

A interação e a comunicação correta entre as diferentes tarefas;

Coordenação do acesso concorrente aos recursos computacionais.

2. Programação Concorrente

Como um programa concorrente pode ser implementado?

1. Como programas separados ou;

2. Como um conjunto de threads criadas por um único programa.

Quanto ao processamento, como essas tarefas podem ser executadas?

1. Por um único processador ou;

2. Vários processadores em um único equipamento ou processadores distribuídos por uma rede.

2. Programação Concorrente

Podemos entender a interação e a comunicação concorrente dividida em

duas classes:

1. Por memória compartilhada ou;

2. Por troca de mensagens (mais simples e robusta).

2. Programação Concorrente

Como ocorre a comunicação por memória compartilhada?

Componentes concorrentes comunicam-se ao alterar o conteúdo de áreas de memória compartilhadas.

Geralmente requer métodos de trava (exclusão mútua).

Como ocorre a comunicação por troca de mensagens?

Componentes concorrentes comunicam-se ao trocar mensagens em que a leitura pode ser realizada de forma:

Síncrona (método rendezvous): o emissor é bloqueado até que a mensagem seja recebida ou;

Assíncrona.

2. Programação Concorrente

Quais são as vantagens do paradigma de programação concorrente?

Aumento de desempenho: aumenta-se a quantidade de tarefas sendo executadas em determinado período de tempo.

Melhor modelagem: determinados problemas computacionais são concorrentes por natureza.

As linguagens mais utilizadas para tais construções são Java e C#.

Utilizam o modelo de memória compartilhada.

Bloqueio fornecido por monitores.

A linguagem Erlang é possivelmente a mais utilizada pela indústria atualmente, entre as linguagens que utilizam a troca de mensagens.

3. Aplicações Concorrentes

A comunicação entre processos concorrentes de uma aplicação basicamente pode ser implementada, como vimos, por meio de:

Variáveis compartilhadas na memória principal ou

Trocas de mensagens.

Nesta situação, é necessário que os processos concorrentes tenham sua execução sincronizada por meio de mecanismos do sistema operacional.

Os mecanismos de sincronização garantem:

A comunicação entre processos concorrentes e;

O acesso a recursos compartilhados.

3. Aplicações Concorrentes

3. Aplicações Concorrentes

Neste exemplo dois processos concorrentes compartilham um buffer para trocar informações por meio de operações de gravação e leitura.

Um processo só poderá gravar dados no buffer caso este não esteja cheio.

Da mesmo forma, um processo só poderá ler dados armazenados no buffer caso exista algum dado para ser lido.

Em ambas situações, os processos deverão aguardar até que o buffer esteja pronto para as operações, seja de gravação, seja de leitura.

4. Especificação de Concorrência

Existem várias notações utilizadas para especificar a concorrência em programas concorrentes.

As partes de um programa que devem ser executadas concorrentemente.

Os exemplos serão expressos em algoritmos com base principalmente na linguagem PASCAL.

A linguagem de programação Concurrent Pascal foi criada para o desenvolvimento de aplicações concorrentes.

Como notação da especificação de concorrência em um programa poderemos usar os comandos FORK e JOIN.

4. Especificação de Concorrência

O programa A começa a ser executado e ao encontrar o comando FORK.

É criado um outro processo para execução do programa B.

O programa B é executado concorrentemente ao programa A.

O comando JOIN permite que o programa A sincronize-se com o programa B.

Quando o programa A encontrar o comando JOIN só continuará a ser processado após o término da execução do programa B.

4. Especificação de Concorrência

Outra forma de especificar concorrência é a utilização de comandos PARBEGIN e PAREND conforme explicado a seguir.

O comando PARBEGIN especifica que a sequência de comandos seja executada concorrentemente em uma ordem imprevisível.

Por meio da criação de um processo (Processo_1, Processo_2, ...) para cada comando (Comando_1, Comando_2,...).

O comando PAREND define um ponto de sincronização.

Onde o processamento só continuará quando todos os processos criados já tiverem terminado suas execuções.

Os comandos delimitados por PARBEGIN e PAREND podem ser comandos simples, como atribuições ou chamadas a procedimentos.

4. Especificação de Concorrência

Exemplo com PARBEGIN e PAREND.

4. Especificação de Concorrência

Exemplo: PARBEGIN e PAREND

X = sqrt(1024) + (35.4 * 0.23) – (302/7)

5. Compartilhamento de Recursos

Considere o programa Conta_Corrente.

Atualiza o saldo bancário de um cliente após o lançamento de débito ou crédito no arquivo Arq_Contas.

Arq_Contas: armazena os saldos de todos os correntistas do banco.

5. Compartilhamento de Recursos

Considerando processos concorrentes pertencentes a dois funcionários do banco que atualizam o saldo (considere o saldo inicial de R$ 300.00) de um mesmo cliente simultaneamente.

A situação de compartilhamento do recurso pode levar à inconsistência.

5. Compartilhamento de Recursos

O processo do primeiro funcionário (Caixa 1) lê o registro do cliente e soma ao campo saldo o valor do lançamento: débito (-R$ 50.00).

Antes de gravar o novo saldo no arquivo, o processo do segundo funcionário (Caixa 2) lê o registro do mesmo cliente, para somar ao campo saldo o valor de outro lançamento: crédito (R$ 100.00).

5. Compartilhamento de Recursos

Independentemente de qual dos processos venha a atualizar o saldo por último (R$ 250.00 ou R$ 400.00) o dado gravado ao final estará inconsistente (o valor correto é R$ 350.00).

Conclusão: Em qualquer situação, onde dois ou mais processos compartilham o mesmo recurso devem existir mecanismos de controle para evitar problemas.

6. Exclusão Mútua

A solução mais simples para evitar os problemas de compartilhamento é:

Impedir que dois ou mais processos acessem um mesmo recurso simultaneamente.

Enquanto um processo estiver acessando determinado recurso, os demais processos que queiram acessá-lo deverão esperar pelo término da utilização do recurso.

Essa ideia é denominada exclusão mútua (mutual exclusion).

6. Exclusão Mútua

A exclusão mútua deve afetar apenas os processos concorrentes somente quando um deles estiver fazendo acesso ao recurso compartilhado.

A parte do código do programa onde é feito o acesso ao recurso compartilhado é denominado região crítica (critical region).

A exclusão mútua utiliza protocolos de acesso à região crítica:

Toda vez que um processo desejar executar instruções de sua região crítica, deverá executar um protocolo de entrada nessa região;

Da mesma forma, ao sair da região crítica um protocolo de saída deverá ser executado.

6. Exclusão Mútua

6. Exclusão Mútua

Além de garantir a exclusão mútua, duas situações devem ser evitadas:

1. Espera Indefinida por Starvation:

Processo nunca consegue executar sua região crítica.

Pode ocorrer também em função da política de escalonamento.

2. Espera Indefinida por Problema em Processo:

Processo fora da sua região crítica impede que outros processos entrem nas suas próprias regiões críticas.

6. Exclusão Mútua

Diversas soluções foram propostas para garantir a exclusão mútua de processos concorrentes, entre elas:

Soluções de Hardware

Soluções de Software

1. Desabilitação de Interrupções

O programa desabilita todas as interrupções antes de entrar em sua região crítica e reabilita após deixar a região crítica.

Principal Problema: a mudança de contexto de processos só pode ser realizada por meio de interrupções.

6.1 Soluções de Hardware

6.1 Soluções de Hardware

2. Instrução TEST-AND-SET

Consiste em utilizar uma instrução de máquina especial.

A instrução é executada sem interrupção.

A instrução é indivisível.

Se dois processos concorrentes invocam esta instrução simultaneamente, só um deles conseguirá executá-la.

Principal Vantagem: a simplicidade de implementação da exclusão mútua.

Principal Desvantagem: a possibilidade de starvation, pois a seleção do processo para o acesso ao recurso é arbitrária.

6.1 Soluções de Hardware

Algoritmo: Test_and_Set(X, Y); O valor lógico da variável Y é copiado para X, sendo então atribuído o valor lógico VERDADEIRO para Y.

6.2. Soluções de Software

1. Primeiro Algoritmo

Garante a exclusão mútua.

Garante a exclusão mútua.

6.2. Soluções de Software

1. Primeiro Algoritmo

O acesso ao recurso compartilhado só pode ser realizado alternadamente.

O tempo de execução de um processo influi na possibilidade de execução da região crítica do outro processo.

Problema com um dos processos pode tornar o outro processo indefinidamente bloqueado, aguardando o acesso ao recurso.

Não garante a exclusão mútua. Possibilidade de espera indefinida.

Garante a exclusão mútua. Possibilidade de espera indefinida.

Garante a exclusão mútua. Soluciona parcialmente a espera indefinida.

Garante a exclusão mútua. Soluciona definitivamente o bloqueio indefinido.

6.2. Soluções de Software

As soluções vistas até aqui implementam a exclusão mútua.

Possuem uma deficiência conhecida como espera ocupada (busy wait).

O processo permanece em looping, testando uma condição.

Consome tempo do processador desnecessariamente.

A solução para a espera ocupada foi a introdução de mecanismos de sincronização.

Permitem que um processo, quando não puder entrar em sua região crítica, seja colocado no estado de espera.

Esses mecanismos, conhecidos como semáforos e monitores.

[Fim] Comunicação entre Processos – Parte 1

“Não se pode ensinar tudo a alguém, pode-se apenas ajudá-lo a encontrar por si mesmo.”

Galileu Galilei

Próximo Módulo: Comunicação entre Processos – Parte 2