Aula 5

Prévia do material em texto

Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
41
APLICAÇÕES CONCORRENTES
Os sistemas multiprogramáveis possibilitaram a estruturação de aplicações, 
de maneira que em partes diferentes do código do programa fosse possível executar 
concorrentemente. Esse tipo de aplicação fi cou sendo chamado de aplicação concorrente, 
tendo como base a execução cooperativa de múltiplos processos ou threads que executam 
uma mesma tarefa em busca de um mesmo resultado. 
Em um único processador e em um sistema multiprogramável os processos se 
Aula 05
CONCORRÊNCIA 
E COMUNICAÇÃO
ENTRE PROCESSOS
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
42
alternam seguindo os critérios de escalonamento estabelecidos pelo sistema operacional. 
Mesmo tendo um paralelismo na execução de instruções, uma aplicação concorrente 
pode ter em seu desempenho uma melhora substancial. Já em sistemas com múltiplos 
processadores, há possibilidade de paralelismo na execução de instruções. As únicas 
vantagens proporcionadas são as da programação concorrente.
As aplicações concorrentes compartilham os recursos de sistema como arquivos, 
registros dispositivos de E/S e área de memória. Esse compartilhamento é comum nos 
sistemas, mas os compartilhamentos entre processos podem ocasionar situações indesejáveis 
e podem até comprometer a execução de aplicações. Mas para evitar esse tipo de problema 
os processos concorrentes devem ter suas execuções sincronizadas. E o mecanismo que faz 
esse sincronismo entre os processos deve ser oferecido pelo sistema operacional, com o 
objetivo de garantir o processamento correto dos programas.
Processos cooperativos são aqueles que podem afetar uns aos outros quando 
em execução, ou seja, um processo pode afetar o outro. O processo cooperativo pode 
compartilhar dados através de arquivos e, como os processos são concorrentes no acesso a 
dados compartilhados, pode resultar em inconsistência de dados.
COMUNICAÇÃO ENTRE PROCESSOS
É com muita frequência que os processos têm que se comunicar uns com os outros. 
Por exemplo, a saída do primeiro processo deve ser passada para o segundo, e isso prossegue 
até a última linha de comando. Assim há necessidade de os processos se comunicarem entre 
si, o que deve ocorrer de uma maneira bem estruturada e sem nenhuma interrupção. 
Vamos ver alguns tópicos em relação à comunicação entre os processos. Primeiro: 
como um processo passa informação para outro; segundo: como garantir que dois ou 
mais processos não invadam uns aos outros quando envolvidos em atividades críticas 
(por exemplo: “suponha que dois processos tentem, cada um, apropriar-se do último 1 
MB de memória; terceiro: saber qual a sequência certa entre os processos quando existe 
uma dependência entre eles (exemplo: se um processo “A” produz dados e o processo 
“B” imprime, o processo “B” deve esperar até que “A” produza os dados para depois 
serem impressos.
Vejamos o seguinte exemplo: se temos um processo de gravação e um processo de 
leitura, e os processos precisam se utilizar do buffer, para que o processo de gravação seja 
executado, o buffer deve estar vazio. O mesmo vale para o processo de leitura, pois ele só 
pode ler os dados no buffer se este estiver com os dados gravados. O que se pode perceber 
é que em ambos os casos os processos deverão aguardar até que o buffer esteja pronto para 
executar as operações, seja de gravação ou de leitura.
Os mecanismos que têm a função de garantir um bom funcionamento entre processos 
concorrentes e os recursos compartilhados são chamados de mecanismos de sincronização. 
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
43
Observe na fi gura 1, logo abaixo, ambos os processos só podem ser executados quando o 
buffer de memória estiver disponível para cada tipo de processo.
 Os programas são sincronizados e sua concorrência pode ser estabelecida através 
de comandos, como os comandos FORK e JOIN, que foram introduzidos por Conway (1963) 
e Dennis e Van Horn (1966). Vejamos no exemplo que se segue uma sintaxe simplifi cada:
O programa 1 começa a ser executado e, ao encontrar o comando FORK, faz com 
que seja criado um outro processo para a execução do programa 2, concorrente do programa 
1. Já o comando JOIN permite que o programa 1 sincronize-se com o 2, ou seja, quando o 
programa 1 encontrar o comando JOIN, continuará a ser processado somente após terminar 
o programa 2.
Muitas vezes, um processo está utilizando uma área que é compartilhada, ou seja, 
o processo, durante uma parte do tempo, está fazendo uma computação interna. Contudo, 
o processo precisa ter acesso à memória ou a arquivos compartilhados, ou tem que fazer 
alguma coisa crítica que pode ocasionar disputas. A parte do programa que tem acesso 
Figura 1
Figura 2
Programa 1; Programa 2
. .
. .
FORK1: .
. .
. .
JOIN1; END.
 .
 .
 END.
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
44
à memória compartilhada é chamada de área crítica (critical region) ou seção crítica 
(critical section). Seria bom se conseguíssemos que dois processos nunca estivessem em 
sua área crítica ao mesmo tempo, pois as disputas seriam evitadas. Por isso, precisamos 
da exclusão mútua (mutual exclusion), ou seja, de algum modo assegurar-nos de que 
outros processos não utilizem uma variável ou arquivo compartilhado que esteja sendo 
utilizado por um processo.
Embora isso pareça ter resolvido nosso problema, há ainda 4 itens que precisamos 
executar para que possamos chagar a uma boa solução:
1. Dois processos nunca podem estar ao mesmo tempo em suas regiões críticas;
2. Nada pode ser afi rmado sobre a velocidade ou o número de CPU;
3. Nenhum dos processos executados fora de sua região crítica pode bloquear 
outros processos;
4. Nenhum processo deve esperar eternamente para entrar em sua região crítica;
Veja na fi gura abaixo uma ideia de como pode ser a utilização da área crítica por 
cada processo.
 
DESABILITANDO INTERRUPÇÕES
Uma solução bastante simples é desabilitar todas as interrupções, logo depois 
de entrar na sua região crítica, e habilitá-las imediatamente antes de sair dela. Com as 
interrupções desabilitadas não pode ocorrer nenhuma interrupção de relógio. A CPU é 
alternada de processo em processo somente como resultado da interrupção de relógio ou 
de outra interrupção. Com a interrupção desligada, a CPU não será alternada para outro 
Figura 3
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
45
processo, assim, um processo pode verifi car e atualizar a memória compartilhada, sem 
temer a intervenção de um outro processo. De modo geral, desabilitar as interrupções não 
é aconselhável, pois pode ocorrer que as interrupções sejam desabilitadas e nunca mais 
sejam habilitadas. Isso poderia acarretar no fi m do sistema. Além disso, se o sistema tiver 
mais de uma CPU, poderia afetar somente a CPU que o executou e as outras continuariam 
a ter acesso à memória compartilhada.
Por outro lado, pode ser conveniente o próprio núcleo desabilitar as interrupções, 
para algumas poucas instruções, enquanto estiver alterando variáveis ou listas, pois se 
ocorrer uma interrupção enquanto uma lista de processos prontos estiver em um estado 
inconsistente, poderá haver disputa. Por isso, a conclusão a que se chega é a de que dentro do 
próprio sistema a técnica de desabilitar as interrupções pode ser muito útil, mas ela se torna 
inadequada como um mecanismo geral de exclusão mútua para processos de usuários.
VARIÁVEL DE IMPEDIMENTO (LOCK VARIABLES)
Podemos também tentar fazer da seguinte forma: criar uma variável com valor 
0, que signifi ca que a memória compartilhada está vazia e pode ser usada, certo? Mas se 
pensamos o seguinte: se um processo verifi ca a variável e ela estiver com valor 0 (zero) 
e, no exato momento em que o processo vai atribuir o valor 1, um outro processo já tenha 
lido o valor 0 (zero) também, os dois vão atribuir o valor 1 (um) para a variável e vão 
tentar ocuparo mesmo espaço, ou seja, a mesma memória. Poderíamos pensar também da 
seguinte maneira: se ao ler a variável o processo verifi car novamente se está com o valor de 
0 (zero) e atribuir valor, novamente ocorreria a disputa pela memória compartilhada.
ALTERNÂNCIA OBRIGATÓRIA
Vamos supor que criamos uma variável de controle. Vamos chamá-la rapidamente. 
Quando o processo encontra essa variável com o valor 0 (zero), então, o processo, que 
chamaremos de processo 0 (zero), entra na região crítica. O processo 1 também encontra 
o valor 0 (zero), só que ele fi ca em um laço fechado, testando continuamente quando a 
variável se torna 1. É bom testar continuamente uma variável até que um valor apareça, o 
que é chamado de espera ociosa (busy waiting). A espera ociosa deve ser evitada, pois toma 
tempo da CPU, ou usada somente quando há uma expectativa razoável de que a espera seja 
breve. Uma variável de impedimento que usa a espera ociosa é chamada de spin lock.
A alternância de processo é indicada quando um processo for bem mais lento que 
outro, pois pode ocorrer de o processo que não esteja na região crítica bloquear o outro 
que queira utilizar a região crítica. Essas alternâncias são proporcionadas por algoritmos, 
ou seja, não há envolvimento de hardware para que ocorra esse tipo de solução, em que os 
processos sejam alternados.
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
46
Algumas soluções foram encontradas para o sincronismo e para que mais de um 
processo não ocupe a região compartilhada ao mesmo tempo. Mas todas as soluções têm 
uma defi ciência que é conhecida como espera ocupada. Na espera ocupada, toda vez que um 
processo não consegue entrar em sua região crítica, por ter um outro processo já ocupando 
a mesma região, o processo permanece em looping, sempre testando uma condição, até que 
seja permitido o acesso à área.
DEADLOCK
Há situações em que o processo fi ca aguardando por recursos que nunca estarão 
disponíveis. Os processos podem competir por recursos que estejam sendo utilizados por 
outros processos. O processo solicita um recurso e caso o recurso não esteja disponível, ele 
entra em estado de espera. O processo em espera pode jamais mudar de estado, pois o recurso 
que ele solicita pode estar sendo ocupado por outros processos que também estão em estado 
de espera. Toda essa situação é consequência, na maioria das vezes, de compartilhamento 
de recursos como dispositivos, arquivos e registros entre processos concorrentes, em que 
a exclusão mútua é exigida. Esse problema é denominado deadlock e se torna cada vez 
mais frequente à medida que os sistemas operacionais evoluem, procurando cada vez mais 
implementar o paralelismo para permitir um número cada vez maior de recursos.
Em um deadlock os processos nunca terminam a sua execução e os recursos do 
sistema fi cam bloqueados, impedindo outros processos de entrar em execução. O problema 
do deadlock existe em qualquer sistema multiprogramável, mas as soluções implementadas 
devem considerar o tipo de sistema e o impacto em seu desempenho. Por exemplo: um 
sistema que controla uma usina nuclear deve ser desenvolvido com mecanismos voltados 
para esse tipo de aplicação e não adotar um sistema de tempo compartilhado comum.
Os sistemas têm que ter um mecanismo de detecção de deadblock, pois é necessário 
que esse mecanismo determine realmente a existência de deadblock, que permite identifi car 
os recursos e processos envolvidos no problema. Os sistemas operacionais devem ter 
estruturas de dados capazes de identifi car cada recurso do sistema. Quando um recurso 
é alocado ou liberado, a estrutura deve ser atualizada. De forma geral, os algoritmos que 
implementam esse mecanismo são feitos para verifi car a existência da espera circular.
Conforme o sistema, o ciclo de busca por deadblock pode variar, pois em sistema de 
compartilhado, o tempo de busca é maior. Claro que isso não compromete o desempenho e a 
confi abilidade do sistema. Nos sistemas de tempo real deve-se constantemente se certifi car 
da ocorrência de deadblock.
Para sanar ou corrigir o deadblock temos uma solução simples, basta eliminar 
os processos envolvidos no deadblock e, claro, deslocar os recursos que são utilizados 
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
47
por eles. Essa eliminação de processos pode não ser tão simples, dependendo do recurso 
que está sendo utilizado, e se um processo estiver atualizando um arquivo ou imprimindo 
uma listagem.
ATIVIDADES 
As atividades referentes a esta aula estão disponibilizadas na ferramenta 
“Atividades”. Após respondê-las, envie-nas por meio do Portfólio- ferramenta do 
ambiente de aprendizagem UNIGRAN Virtual. Em caso de dúvidas, utilize as ferramentas 
apropriadas para se comunicar com o professor.
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN
48