Programação concorrente: diferenças entre revisões
Conteúdo apagado Conteúdo adicionado
Linha 35:
Como sistemas concorrentes necessitam a utilização de recursos compartilhados, a programação concorrente geralmente requer o uso de algum método de árbitro, um elemento neutro, para coordenar o acesso a tais recursos. Isso introduz a possibilidade do aparecimento de problemas com decisões não determinísticas, apesar de que o desenvolvimento cuidadoso de árbitros pode reduzir a probabilidade de tais situações aparecerem.
Este é um exemplo de como resolver o problema da indefinição do resultado da concorrência, acima:
<source lang="c" line>
bool saque( int quantia )
{
pthread_mutex_lock(v_bloqueio);
if( balanco > quantia )
{
balanco = balanco - quantia;
pthread_mutex_unlock(v_bloqueio);
return true;
}
else
{
pthread_mutex_unlock(v_bloqueio);
return false;
}
}
</source>
Nesta alteração, a instrução da linha 3 diz para o processo iniciar o bloqueio marcando na variável "v_bloqueio" que foi ele quem bloqueou. Se esta variável já estiver marcada como "bloqueada", o processo aguarda sua liberação para seguir em frente. Caso contrário, executa as demais instruções. Quando executar o comando para desbloquear, seja na linha 7 ou 12, o próximo processo que estiver aguardando a obtenção do bloqueio irá verificar que pode continuar. Dessa forma, apenas um processo por vez executa o teste e alteração da variável "balanco", com seu valor já atualizado e evitando assim a impresivibilidade do resultado.
Obviamente, o contratempo desta abordagem é "afunilar" o processamento paralelo. No pior caso, se todos os processos chegarem a este trecho ao mesmo tempo, apenas um de cada vez irá executá-lo. Entretanto, se estas situações forem uma porção mínima em todo o sistema, esta limitação será insignificante, dado a vantagem do restante do processamento paralelo.
== Suporte em linguagens ==
| |||