Coordenação entre

Tarefas

Eduardo Feitosa
efeitosa@icomp.ufam.edu.br
 Problema da Concorrência
● Quando duas ou mais tarefas acessam simultaneamente um
recurso compar1lhado, podem ocorrer problemas de
consistência dos dados ou do estado do recurso acessado
 Problema da Concorrência
● Os erros e inconsistências gerados por acessos concorrentes
são denominados:
○ Condições de disputa
○ Condições de corrida (race condi)ons).

● Envolvem operações de escrita.

Condições de Disputa
 Condições de Disputa
condição de corrida ponto pra gerada de lock = erro ou inconsistencia dee duas ou mais tarefas brigando por um trabalho compartilhado
 Condições de Disputa
● Os erros e inconsistências gerados por acessos concorrentes
a dados compar1lhados são denominados condições de
disputa, ou condições de corrida (do inglês race condi)ons).

● Ocorrem em sistemas onde várias tarefas acessam de forma

concorrente recursos compar1lhados sob certas condições.
○ São erros dinâmicos, ou seja, erros que não aparecem no código
fonte e que só́ se manifestam durante a execução
○ Se manifestam apenas quando certos entrelaçamentos
ocorrerem
 Condições de Disputa
● Condições de Bernstein
○ Formalizam as condições de disputa entre tarefas paralelas
○ Dadas duas tarefas t1 e t2, sendo R(ti) o conjunto de variáveis
lidas por ti e W(ti) o conjunto de variáveis escritas por G, essas
tarefas podem executar em paralelo sem risco de condição de
disputa (t1 || t2) se e somente se as seguintes condições forem
atendidas:

Se os dois nao quiserem escrever nas mesmas variaveis

 Seções Críticas
Todo codigo que tiverr trecho que pode acontecer a condicao de corrida recebe o nome de seção crítica

● Seções Crí1cas (SC) ou regiões crí1cas são todos os trechos

de código que manipulam dados compar1lhados onde
podem ocorrer condições de disputa.

● A solução para SC óbvia é que apenas uma tarefa pode estar

na seção crí1ca a cada instante.
sempre que garantir que uma unica tarefa ta acessando naquele instante é a exclusao mútua

● Essa propriedade é conhecida como exclusão mútua.

 Exclusão Mútua
onde começa e onde termina = resolve o problema da seção crítica

● Qualquer solução de exclusão mútua define os limites de

início e fim de cada SC.

● São definidas duas primi1vas

○ enter(ta, csi) - tarefa ta deseja entrar na seção críGca csi. (é
bloqueante)
○ leave(ta, csi) - tarefa ta está saindo da seção críGca csi.

void depositar (conta_t* conta, int valor) {

enter (conta->numero) ; // tenta entrar na seção crítica
conta->saldo += valor ; // está na seção crítica
leave (conta->numero) ; // sai da seção crítica
}
 Exclusão Mútua
● As soluções propostas devem atender a alguns critérios
básicos enumerados a seguir:
○ Exclusão mútua: somente uma tarefa pode estar dentro da seção
críGca em cada instante.
nao pode esperar pra sempre

○ Espera limitada: uma tarefa que aguarda acesso a uma seção

críGca deve ter esse acesso garanGdo em um tempo finito.
○ Independência de outras tarefas: a decisão sobre o uso de uma
seção críGca deve depender somente das tarefas que estão
tentando entrar na mesma.
○ Independência de fatores 6sicos: a solução deve ser puramente
lógica e não depender da velocidade de execução das tarefas, de
temporizações, do número de processadores no sistema ou de
outros fatores Psicos.
Soluções para Sessões
Críticas
 Soluções para Seções Críticas
● Soluções de Hardware
○ Inibição de interrupções e Instrução TSL
● Soluções de soOware com busy wait
○ Variável de bloqueio, Alternância estrita, Algoritmo de Decker,
Algoritmo de Peterson
● Soluções de soOware com bloqueio
○ Sleep / Wakeup, Semáforos, Monitores
 Inibição de interrupções
nao tem preempcao so quem executa e quem ta na seçao critica

● Solução simples para as primi1vas enter e leave que impede

as trocas de contexto dentro da seção crí1ca.

● Ao entrar, a tarefa desa1va (mascara) as interrupções que

possam provocar trocas de contexto e rea1va ao sair da
seção crí1ca.

● Problemas ao desligar interrupções:

○ A preempção não funciona.
○ DisposiGvos de E/S deixam de ser atendidos pelo núcleo.
○ A tarefa na seção críGca não pode realizar operações E/S.
○ Só funciona em sistemas monoprocessados.
 Solução Trivial (não funciona)
(solucao da espera)
variavel de espera vai fazerr comecar ao mesmo tempo e invadir as regioes uma da outra
 Alternância de Uso
● Consiste em definir uma variável turno, que indica de quem
é a vez de entrar na seção crí1ca
○ Essa variável deve ser ajustada cada vez que uma tarefa sai da
seção críGca, para indicar a próxima tarefa a usá-la

sempre inicia pela primeira tarefa

so permite entrar na regiao critica a tarefa do turno adequado

● Questões
o Velocidade de entrada ditada pelo processo mais lento
o Se um processo falha o outro jamais entra na região críGca
`problemas nao se recuperam, todos param de funcionar. So restaurando o proesso
 Algoritmo de Peterson
● Baseada na indicação de uso

próxima q quer

nao é uma ideia usual, mas funciona

 Operações Atômicas
● Proje1stas de hardware criaram instruções em código de
máquina que permitem testar e atribuir um valor a uma
variável de forma atômica (indivisível, sem possibilidade de
troca de contexto entre essas duas operações).
fazer uma unica vez testando uma variavel sem problema

● A execução atômica das operações de teste e atribuição

impede a ocorrência de condições de disputa sobre a
variável busy.

● Um exemplo de operação atômica simples é a instrução de

máquina Test-and-Set Lock (TSL)
Operações Atômicas

(temp)
 Operações Atômicas
● Os mecanismos de exclusão mútua usando instruções
atômicas são amplamente usados no interior do sistema
operacional, para controlar o acesso a secções cri1cas
dentro do núcleo, como descritores de tarefas, buffers de
arquivos ou de conexões de rede, etc.

● Nesse contexto, eles são muitas vezes denominados

spinlocks.
 Problemas
● O acesso concorrente de diversas tarefas aos mesmos
recursos pode provocar problemas de consistência, as
chamadas condições de disputa.

● Uma forma de eliminar esses problemas é forçar o acesso a

esses recursos em exclusão mútua, ou seja, uma tarefa por
vez.

● Contudo, apesar das soluções garan1rem a exclusão mútua,

elas sofrem de problemas que impedem seu uso em larga
escala nas aplicações de usuário
 Problemas
● São elas: se quase estiver terminando todo o progresso se perde
o Ineficiência: as tarefas que aguardam o acesso a uma seção
criGca ficam testando conGnuamente uma condição, consumindo
tempo de processador sem necessidade.
§ O procedimento adequado seria suspender essas tarefas até que a
seção crí5ca solicitada seja liberada.
o Injus9ça: a não ser na solução de alternância, não há garanGa de
ordem no acesso à seção críGca
§ Dependendo do quantum e da polí5ca de escalonamento, uma tarefa
pode entrar e sair da seção crí5ca várias vezes, antes que outras tarefas
consigam acessá-la.
o Dependência: na solução por alternância, tarefas desejando
acessar a seção críGca podem ser impedidas de fazê-lo por
tarefas que não têm interesse na seção críGca naquele momento.
programador que precisa gerenciar todos os processos
 Problemas
● Por estas razões, as soluções com espera ocupada são pouco
usadas na construção de aplicações.

● Seu maior uso se encontra na programação de estruturas de

controle de concorrência dentro do núcleo do sistema
operacional e na construção de sistemas de computação
dedicados, como controladores embarcados mais simples.
Coordenação entre
Tarefas

Eduardo Feitosa
efeitosa@icomp.ufam.edu.br