10.concurrency

10
Concorrência

 Por que concorrência?.
 Programas e processos.
 Problemas com a concorrência.
 Interações de processos.
 Primitivas de concorrência
 Abstrações para controle da concorrência
7-1

Por que concorrência? (1)

 A concorrência foi inicialmente introduzida nos
computadores com o objetivo de melhorar o desempenho
• Realização de E/S e operações da CPU em simultâneo, que
acarretou o surgimento da programação concorrente

 A programação concorrente ficou muito complexa para o
programador de aplicações
• Restringiu-se basicamente aos sistemas operacionais, que seriam os
arquétipos dos programas concorrentes

7-2


 Os sistemas de multiprogramação objetivam maximizar o
uso dos recursos através da execução de dois ou mais jobs
concorrentemente

 Sistemas de multiacesso ou servidores estendem a
multiprogramação, permitindo que vários jobs executem,
cada um em benefício de um usuário remoto

 Sistemas de multiprocessador estão presentes em
computadores que várias CPUs operando simultaneamente
na execução de jobs que compartilham uma memória
principal
7-3


 Sistemas distribuídos consistem de vários computadores
que não apenas operam independentemente, mas que
também se intercomunicam eficientemente
 A medida que a velocidade das CPU atingem limites
tecnológicos, ganhos futuros em desempenho dependem de
uma melhor exploração da concorrência
 A concorrência em linguagem de programação é
necessária para permitir a modelagem mais precisa dos
aspectos concorrentes do mundo real
 Desenvolvimento de arquiteturas de computadores novas e
altamente concorrentes 7-4

Programas e Processos (1)

 Um processo seqüencial é um conjunto totalmente ordenado
de passos, cada passo sendo uma mudança de estado em
algum componente de um sistema de computação
 Um programa seqüencial especifica as possíveis mudanças
de estado de um processo seqüencial, as quais ocorrem numa
ordem determinada pelas estruturas de controle do programa
 Um programa concorrente especifica as possíveis
mudanças de estados de dois ou mais processos seqüenciais
• Nenhuma ordem é naturalmente definida entre as mudanças de
estados de um processo em relação a mudanças de estados de
quaisquer outros processos
• Dizemos que estes processos são executados concorrentemente,
7-5
podendo até mesmo serem executados simultaneamente

Programas e Processos (2)

 O exemplo de um processo seqüencial é a execução de um
programa numa linguagem como Pascal ou C
• Os eventos de um processo como este correspondem à atualização das
variáveis do programa
• Tais eventos são totalmente ordenados pelas regras de seqüenciamento da
linguagem, que definem como o controle é transferido de um comando
para outro

 Por causa da total ordenação dos eventos, pode-se associar à
passagem do tempo físico as mudanças de estado de um
programa seqüencial
• Mudanças de estado de baixo nível podem não ser totalmente ordenadas
no tempo, porém como não são observáveis pelo programador e como
não afetam o resultado final, não são consideradas relevantes
7-6

Problemas com a concorrência (1)

 O que faz os programas concorrentes serem diferentes dos
programas seqüenciais?
 Não-determinismo (1)
• Um programa determinístico é aquele que segue uma seqüência de
passos que pode ser prevista caso saibamos seus dados de entrada
– Programas seqüenciais corretos são sempre determinísticos
– Logo, seu comportamento pode ser completamente reproduzido, tornando
praticável a verificação de programas por meio de testes
• Existem construções que introduzem alguma imprevisibilidade em
programas seqüenciais como:
– Comandos colaterais
– Comandos condicionais não determinísticos
– Avaliação colateral de subexpressões, onde uma destas subexpressões pode
provocar efeitos colaterais em outra
7-7


• Em cada um destes casos
– O processador da linguagem é livre para escolher a ordem de
execução
– O comportamento do programa poderá ser diferente com
processadores distintos, mas certamente será o mesmo num
processador de linguagem específico
– Logo o comportamento do programa poderá ser reproduzido
• Um programa concorrente, por outro lado, é verdadeiramente não-
determinístico
– A ordem de execução dos passos é imprevisível, assim como o
resultado final, mesmo num processador de linguagem específico
• Em geral, deseja-se escrever programas efetivamente
determinísticos, isto é, um programa cujo resultado global seja
previsível
7-8


• Entretanto, um programa concorrente incorreto pode se comportar
como previsto a maior parte do tempo, mas pode desviar de seu
comportamento previsto de modo intermitente e irreproduzível

– Erros de programação concorrente são dos mais difíceis de se
diagnosticar

– A pesquisa de meios para preveni-los é uma grande motivação na área
de programação concorrente

7-9


 Dependência de Velocidade (1)
• Um programa seqüencial é independente de velocidade porque
sua correção não depende da velocidade com que é executado
• Um programa concorrente, em geral, é dependente de velocidade,
visto que suas saídas podem depender da velocidade relativa de
execução dos processos que o compõem
– Como conseqüência, pequenas flutuações na velocidade dos
processadores e dos dispositivos de E/S podem levar ao não-
determinismo
– Quando velocidades absolutas devem ser levadas em conta, tem-se
um programa em tempo real
– Quando o resultado é dependente de velocidade, diz-se que existe
uma condição de corrida (race condition)

7-10


• Exemplo: condição de corrida
– Suponha que dois processos P e Q atualizam a mesma variável s do
tipo String
 In P: s := "ABCD";
In Q: s := "EFGH";

– Se P completa a atribuição antes de Q começar a atribuição, o valor
final de s é "EFGH"
– Se Q completa a atribuição antes de P começar a atribuição, o valor
final de s é "ABCD"
– Mas, supondo que P e Q atualizam s um caractere por vez, o valor
final de s pode ser um dentre 60 valores, ou seja, pode haver um
resultado diferente cada vez que P corre com Q 7-11


• Imagine-se caos do problema anterior com múltiplos processos e
variáveis
– Um dos objetivos da programação concorrente é prevenir este pesadelo
 Uso de variáveis atômicas – aquelas que só podem ser inspecionadas ou
atualizadas como um todo
» Em Java, referência a objetos e variáveis de tipos primitivos diferentes de
long e double são sempre atômicas

» Em Ada, qualquer variável pode ser declarada atômica com a cláusula
pragma atomic(v);, embora o compilador seja livre para rejeitá-la

– Entretanto, tais medidas estão longe de ser uma solução completa

7-12

 Deadlock (1)
• Deadlock é o bloqueio permanente de um conjunto de processos que, ou
estão competindo por recursos, ou estão competindo para se comunicar uns
com os outros
• O deadlock pode ocorrer num sistema de processos e recursos, se e
somente se, as seguintes condições existirem todas juntas
– Exclusão mútua: os processos podem ter acesso exclusivo aos recursos
– Aquisição incremental: os processos continuam a prender recursos previamente
alocados, enquanto esperam que a requisição de um novo recurso seja atendida
– Não preempção: recursos não podem ser removidos de um processo até que ele
voluntariamente o libere
– Espera circular: pode existir um ciclo de recursos e processos no qual cada
processo está esperando por um recurso que está preso pelo próximo processo no
ciclo

7-13


 Deadlock (2)
• Vários enfoques podem ser empregados para solucionar o problema do
deadlock
– Ignorar o deadlock e caso ele aconteça, resolver o problema manualmente pela
interferência do operador do sistema, destruindo alguns processos ou
reinicializando todo o sistema
– Outra opção é detectar o deadlock e então recuperar-se dele automaticamente,
de modo que o sistema como um todo possa continuar funcionando
– Prevenir o deadlock pela eliminação de uma ou mais condições necessárias à
sua ocorrência
 Eliminação da aquisição incremental de processos – ou tudo ou nada
 Eliminação da espera circular – imposição de uma ordem de aquisição de recursos

– Fazer com que os escalonadores do sistema evitem ativamente o deadlock pela
determinação antecipada dos processos que se pretende alocar
 Algoritmo do banqueiro 7-14


 Starvation (1)
• Um sistema concorrente tem a propriedade de avanço finito se
houver a garantia de que todo processo avançará em algum período
suficientemente grande de tempo (mas finito)
– Para atender a esta condição o sistema deve
 Ser livre de deadlock
 Ter um escalonamento justo
» Escalonamento é a alocação de recursos para processos no tempo, tendo por
meta algum objetivo, como um tempo de resposta adequado ou a alta utilização
da CPU

» O escalonamento justo assegura que nenhum processo necessitando de um
recurso vai ficar esperando indefinidamente para obter o recurso por causa da
demanda de outros processos

7-15


 Starvation (2)
• Usa-se o termo starvation quando um processo fica esperando
indefinidamente para executar por causa de um escalonamento
injusto
– Uma situação de starvation pode ocorrer quando o acesso a CPU é
dado preferencialmente aos processos de alta prioridade
 Neste caso, deste que se tenha um sempre um processo de alta prioridade
na vez para usar a CPU, um processo de baixa prioridade pode ficar
esperando indefinidamente a sua vez para executar

7-16

Interações de Processos (1)

 A notação C; K especifica a composição seqüencial dos
comandos C e K
 A notação C, K especifica a composição colateral dos
comandos C e K
 A diferença entre os dois é que na composição seqüencial
todas as ações de C devem ser encerradas antes que qualquer
ação de K comece; enquanto na composição colateral as ações
de C e K podem ser intercaladas arbitrariamente
 Nenhuma das notações admite a possibilidade dos comandos
C e K serem executados simultaneamente

7-17


 Para isto, usa-se o comando paralelo B || C, que é a
composição concorrente dos comandos B e C
• Especifica que dois ou mais comandos podem ser executados
concorrentemente
• B || C não requer a execução simultânea dos comandos B e C, mas
permite isto
• B || C também permite a execução colateral e a execução seqüencial
dos comandos B e C como casos particulares de concorrência

 Programas concorrentes se distinguem dos seqüenciais não
apenas pela presença da composição concorrente, mas
também pela presença de operações que causam interações
entre processos, que pode ser de vários tipos
7-18


 Processos independentes (1)
• Os comandos B e C são independentes se nenhum passo de B pode
afetar o comportamento de qualquer passo de C e vice-versa
– Se B e C são independentes, segue que a composição seqüencial B; C é
equivalente a composição seqüencial C; B
– Também pode-se concluir que B; C, C; B e C, K são equivalentes a
C || K quando C e K são independentes
– Logo, segue que a composição concorrente de processos independentes é
determinística
• Este é um resultado importante porque
– Prover a base para sistemas servidores de multiacesso, que podem
executar muitos jobs pela multiprogramação de um ou mais processadores
– Sendo os jobs independentes, os usuários não precisam tomar precauções
especiais por conta da concorrência
7-19


 Processos independentes (2)
• Infelizmente, não é decidível, em geral, se os comandos B e C são
realmente independentes
– Entretanto, uma condição suficiente para independência é que
nenhum comando possa atualizar uma variável que outro comando
inspeciona ou atualiza
 Embora possa ser verificado, em princípio, em tempo de compilação,
deve-se empregar uma definição abrangente de variável, como qualquer
componente do sistema cujo estado possa ser alterado

7-20


 Processos competidores (1)
• Os comandos B e C competem se cada um precisa ganhar acesso
exclusivo ao mesmo recurso r para executar alguns de seus passos

• Seja B a seqüência B1;B2;B3 e C a seqüência C1;C2;C3

– Os subcomandos B1, B3, C1 e C3 são independentes , ou seja, nenhuma deles
usa o recurso r

– B2 e C2 requerem acesso exclusivo ao recurso r e não devem executar
simultaneamente nem sua execução se sobrepor no tempo

 B2 e C2 são chamados de seções críticas com respeito ao recurso r
7-21


– B || C deveria ser executado numa das seguintes maneiras
 ...; B2; ...; C2; ...
 ...; C2; ...; B2; ...
mas não como
 ...; B2 || C; ...
– Então, B || C tem dois possíveis resultados, que são exatamente os
resultados das seqüências B; C e C; B, respectivamente
 Qual destes resultados realmente ocorre dependerá das velocidades relativas
com que B e C são executados e isto não é previsível em geral
 Caso o efeito de uma seção crítica dependa do estado do recurso quando ele é
adquirido e se a seção muda o estado do recurso, então o sistema B || C é não-
determinístico em geral
• Um programa concorrente possui a propriedade de safety (segurança)
se suas seções críticas nunca se sobrepõem no tempo
– É seguro no sentido de que todos os comando que ele aplica sobre um
recurso terá o seu efeito seqüencial normal 7-22


• Exemplo: Não determinismo apesar da exclusão mútua
– Suponha que dois processos P e Q atualizam a variável i do tipo Integer,
atômica e com valor inicial 0
– Os comandos de atribuição de P e Q estão em exclusão mútua, um em
relação ao outro

 In P: i := i + 1;
In Q: i := 2 * i;
– Existe corrida (race) entre P e Q, mas os dois únicos possíveis resultados
em i são 1 (Q executa a atribuição antes de P) ou 2 (P executa a atribuição
antes de Q)
 É que se chama de não determinismo delimitado: o resultado não é previsível,
mas pertence a um conjunto conhecido e fixo de saídas, todas igualmente
aceitáveis
7-23


 Processos comunicantes (1)
• Sejam os comandos B e C como vistos anteriormente
– Existe comunicação de B para C caso B2 produza dados que C2 consuma,
de modo que B2 termine antes de C2 começar
 Neste caso, B || C tem o mesmo resultado que B; C
 Um pipeline ocorre quando existe uma encadeamento de processos, cada um
consumindo a saída do processo anterior e produzindo a entrada do processo
seguinte
» Exemplo: comandos pipeline do UNIX – "B | C"

• Os processos B e C se intercomunicam caso exista comunicação em
ambas as direções
– Isto torna os possíveis resultados de B || C muito mais numerosos e
– Força a impor uma severa disciplina nas formas de intercomunicação
permitidas, caso se deseje preservar o gerência intelectual dos programas
7-24

Primitivas de Concorrência (1)

 Conjunto de operações de baixo nível que afeta a
concorrência através de sua criação, controle e destruição
• Fundamental para entender as construções de alto nível das
linguagens de programação concorrente

 Tipos de processos (1)
• Processos convencionais – havyweight: é a execução de um programa
para o qual o sistema operacional prover um espaço de
endereçamento, a alocação de memória principal e também o
compartilhamento da CPU e de outros recursos
– Sobrecarga substancial para criação de processos e também na troca de
contexto de um processo para o outro pelo sistema operacional

7-25


 Tipos de processos (2)
• Processos thread – lightweight: é um fluxo de controle através de um
programa, mas que não possui recursos computacionais
independentes
– Uma thread existe dentro de um processo e depende dos recursos do
processo
 A troca de contexto de thread para thread de um processo pode ser
implementada de forma simples e eficiente
» Java usa o termo thread
» Ada usa o termo tarefa (task)

• No livro-texto, termo processo será usado com neutralidade,
independente de ser havyweight ou lightweight

7-26


 Criação e controle de processos (1)
• As operações primitivas relativas processos são as seguintes
– create um processo filho novo e inativo
– load o código de programa a ser executado por um processo
– start a execução de um processo
– suspend a execução de um processo (temporariamente)
– resume a execução de um processo (suspenso)
– permitir que um processo stop ele mesmo ao fim de sua execução
– permitir que seu criador wait por pelo processo para parar
– destroy um processo parado, liberando quaisquer recursos alocado
para ele
7-27


• É sempre conveniente combinar as operações create, load e start
numa única operação, em geral chamada fork e combinar wait e
destroy numa única operação chamada join
– fork é sempre definido de modo que o programa do processo filho é
uma cópia exata do programa do processo pai
– No sistema operacional UNIX, a operação fork é uma função sem
parâmetros que retorna um inteiro
 No processo pai este inteiro é a identificação do novo processo filho criado,
enquanto no processo filho, este inteiro é zero
• As primitivas são bem gerais, permitindo a criação de quaisquer
sistemas de processos concorrentes ativos
– Têm a desvantagem de não revelar com clareza o fluxo do controle do
programa, que se desenvolve dinamicamente
7-28


• Exemplo: forking um novo processo no UNIX
– child_id := fork;
if child_id = 0 then
programa filho
else
continua programa pai

– O UNIX não tem operação join. Um processo é destruído
automaticamente quando termina

• Além de operações para criação e terminação de processos, é preciso
operações que permitam uma comunicação e competição pacífica
entre os mesmos

7-29


• Para permitir que as seções críticas de processos competidores sejam
disjuntas no tempo, as operações primitivas acquire(r) e relinquish(r)
são usadas para obter e liberar, respectivamente, o acesso exclusivo
ao recurso r
– Caso r já esteja alocado, acquire(r) bloqueia o processo que a executou

– Quando relinquish(r) é executado pelo processo que no momento detém
o recurso r, r se torna livre para ser realocado e os processos que estão
esperando por r são reescalonados
 Um desses processos pega r exclusivamente, completando sua operação
acquire(r)

7-30


• Um par de operações similares suportam a comunicação entre
processos:
– Um processo transmissor chama a operação transmit(c), que envia uma
mensagem notificando a ocorrência de um condição c
 c pode ser, por exemplo, "operação de E/S terminada" ou "CPU 2 foi
reiniciada"
– O processo receptor chama a operação receive(c), que o bloqueia até que
a condição c ocorra
– A operação transmit pode se comunicar com um processo receptor
específico ou ser na forma de difusão (broadcast), tornando a
transmissão disponível a qualquer receptor interesado
– Caso não haja um receptor apto no momento da transmissão, ela pode se
perder ou pode ser armazenada – o projeto das primitivas determina o
tipo de comportamento 7-31


 Interrupções
– Uma interrupção é, na prática, uma chamada de procedimento invisível
inserido aleatoriamente em algum ponto do programa!
• Usadas em operações de entrada e saída, para indicar que uma
operação autônoma de E/S terminou
• Se o dispositivo de E/S for visto como um processo externo, a
interrupção pode tratada como um mecanismo para comunicação entre
processos
– Estendendo este conceito, pode-se permitir que um processo (interno)
interrompa outro – comando kill no UNIX
• Trocas de contextos, em geral, são implementadas com interrupções
– Combina níveis de prioridade e possibilidade de inabilitação de
interrupções
7-32


 Algoritmos spin locks e espera-livre (1)
• Um spin lock é um loop de espera ocupada no qual um processo espera
para acessar (exclusivamente) um recurso compartilhado através de
repetidos testes num flag que indica se o recurso está livre
• A primeira pessoa a conseguir este feito (um algoritmo que
implementasse exclusão mútua) foi o matemático Dekker em 1968
num trabalho apresentado por E. Dijkstra
– O trabalho apresenta uma série de tentativas incorretas de implementação,
que ilustram as dificuldades encontradas pelo programador para lidar com
acesso exclusivo a variáveis compartilhadas
– Assume a serialização justa nas operações de acesso à memória realizadas
concorrentemente pela CPU/interface de memória
7-33


• Série de tentativas que culminaram no algoritmo de Dekker (1)
– Assume-se a existência de dois processos 1 e 2, cada um executando um
programa com a seguinte forma (self sendo 1 ou 2)

– repeat
código não crítico para processo self;
acquire(r);
seção crítica para processo self;
relinquish(r);
exit when processo self estiver finalizado;
until processo self ser terminado

com um padrão cíclico de acesso ao recurso protegido r
7-34


– A primeira é usar uma variável turn, inicializada com 1 ou 2, que indica
quais dos dois processos tem permissão para entrar na sua seção crítica.
Cada processo self implementa as primitivas de exclusão como segue

– acquire(r):
while turn = other loop null; end loop;

relinquish(r):
turn := other

– Isto certamente garante que apenas um dos processos entre por vez na sua
seção crítica. Entretanto, é uma solução é muito rígida uma vez que impõe
uma ordem alternada de entrada dos processos na seção crítica
7-35

– Uma segunda tentativa usa um array claimed, com um valor booleano para
cada processo, indicando se este processo reclamou o direito de entrar na sua
seção crítica. Ambos os componentes de claimed são inicializados com false
– acquire(r):
while claimed(other) loop null; end loop;
claimed(self) := true

relinquish(r):
claimed(self) := false

– O algoritmo falha se o processo 1 (digamos) está num ponto após ter
encontrado claimed[other] = false e antes de fazer claimed[self] = true.
Neste momento específico abre-se uma brecha para que o processo 2 entre no
seu loop e descubra que claimed[self] ainda é = false. No caso, ambos os
processos fariam claimed[self] igual true e poderiam entrar nas suas seções
críticas concorrentemente. Logo, a exclusão mútua não está garantida
7-36


– Uma maneira de consertar tal problema seria modificar a operação acquire(r)
como segue

– acquire(r):
claimed(self) := true;

– Mas, nesta situação, um problema surge caso o processo 1 (digamos) esteja
num ponto após fazer claimed[self] = true e antes de entrar no loop. Isso
permite que o processo 2 faça o mesmo, ficando ambos os processos
reclamando uso do recurso compartilhado indefinidamente e nunca mais
conseguirão entrar na sua seção crítica
7-37


– Corrige-se essa falha permitindo que cada processo retire sua reclamação
temporariamente durante o loop, dando a oportunidade ao outro processo para
prosseguir
– acquire(r):
while claimed(other) loop
claimed(self) := false;
end

– Esta solução funciona com sucesso na maior parte das situações, mas tem um
falha fatal. Caso os dois processos executem exatamente a uma mesma
velocidade e em perfeita fase, pode acontecer que nenhum dos processos
descubra que o outro está oferecendo uma chance para ele continuar. Esta
solução falha porque é dependente de velocidade 7-38


• Algoritmo de Dekker para exclusão mútua
– Combina as melhores características das tentativas anteriores. Usa as variáveis
turn e claimed, como inicializadas anteriormente, do seguinte modo
– acquire(r):
while claimed[other] loop
if turn = other then
claimed(self) := false;
while turn = other loop null; end loop;
end if;
end loop;

relinquish(r):
turn := other;

– O algoritmo de Dekker é bastante complexo e difícil de generalizar para mais
de dois processos preservando a justiça. O algoritmo de Peterson, descoberto
em 1981 está livre destes problemas 7-39


• Algoritmo de Peterson para exclusão mútua

– acquire(r):
turn := other;
while claimed(other) and (turn = other)
loop null; end loop;

relinquish(r):

7-40


• O código baseado em spin locks pode apresentar problemas
– A otimização de loops pode pré-alocar variáveis em registradores, de tal forma
que a sua atualização num processo não é percebida pelos outros
 Pode-se prevenir isto em C, C++ e Java declarando a variável com o modificador
volatile
» Em Java, variáveis long e double declaradas voláteis passam a ser também atômicas, assim como as
demais variáveis de tipos primitivos, porém, não há como garantir a volatilidade dos elementos de um
array em Java!

 Em Ada, uma variável declarada como atômica é automaticamente volátil, que
também pode ser declarada volátil explicitamente
» pragma volatile(v);

» pragma volatile_componentes(a);
7-41


• Spin locks são onerosos em tempo de CPU
– A sobrecarga à CPU limita o desempenho de um sistema altamente concorrente

– Os algoritmos de espera-livre conseguem reduzir a sobrecarga, mesmo sem
aplicar funções de bloqueio – que fazem um processo suspender a si mesmo
 Funções de bloqueio podem provocar uma regressão infinita se chamadas pelo
escalonador do sistema operacional para implementação da exclusão mútua à suas
próprias variáveis

 Tais algoritmos podem precisar de instruções especiais que permitem a atualização
atômica de mais de uma posição de memória
» A memória cache pode ser um problemas em sistemas multiprocessados!

 O algoritmo de Simpson, de 1990, é um desses algoritmos de espera-livre, e não usa
bloqueios ou spin locks
7-42


 Eventos (1)
• Um evento representa uma categoria de mudanças de estados, cuja
ocorrência deve ser comunicada para um conjunto de processos
– Implementado pelas operações event-wait(e) e event-signal(e), com e sendo
um valor de um tipo abstrato de dado
 Quando um processo executa event-wait(e), ele fica bloqueado, esperando pela
próxima ocorrência de um evento de categoria e

 A operação event-signal(e) faz com que todos os processos que estão bloqueados
por e fiquem prontos para executar novamente

7-43


 Eventos (2)
• Exemplo: spin lock com bloqueio
– Implementação de uma versão com bloqueio da operação acquire(r), com
cada recurso r associado a um evento r-freed que é sinalizado periodicamente
– Usando o algoritmo de Peterson, tem-se

– acquire(r):
turn := other;
while claimed[other] and (turn = other) loop
event-wait(r-freed);
end loop;

7-44


 Eventos (3)
• Considerado como primitivas de comunicação, eventos têm desvantagens
– As operações wait e signal não são comutativas, sendo sujeitas a dependência
de velocidade
– A operação event-signal(e) desperta todos os processos bloqueados no
evento e, de modo que esta implementação de transmit é interpretada como
broadcasting (difusão)
– Eventos não são úteis para exclusão mútua, devendo-se ter um suporte em
separado para isto (como spin locks ou interrupções)
 Apesar das desvantagens, o uso de eventos combinados com interrupções proveu a
base original para bem sucedida gerência de processos na família de sistemas
operacionais UNIX
7-45


 Semáforos (1)
• Um semáforo é uma variável S do tipo inteiro e um grupo associado de
processos esperando para executar, sobre a qual apenas duas operações
atômicas podem ser realizadas, além de uma operação de incialização
– P(S): if S ≥ 1 then
S := S − 1
else o processo em execução se coloca no grupo de processos associados a S que estão
esperando para executar e libera a CPU
end if;

– V(S): if fila de processos de S é não vazia then
remova um processo que está esperando e o coloque disponível para executar
else
S := S + 1
end if;
7-46


 Semáforos (2)
• Exemplo: implementação de exclusão mútua

 Shared Variable
var S: semaphore := 1;

Process i Process j

loop loop
... ...
P(S); P(S);
Acessa seção crítica Acessa seção crítica
V(S); V(S);
... ...
end loop; end loop;

7-47


 Semáforos (3)
• Semáforos são comutativos, sendo adequados para implementação de
sincronização – exemplo para o problema produtor/consumidor
 Shared Variable
var X: semaphore := 1;
F,E: semaphore := 0,1;
buffer: Char;

Process Producer Process Consumer
var nextChar: Char; var nextChar: Char;

loop loop
GetChar(nextChar); P(F);
P(E); P(X);
P(X); nextChar := buffer;
buffer := nextChar; V(X);
V(X); V(E);
V(F); PutChar(nextChar);
end loop; end loop; 7-48


 Semáforos (5)
• No exemplo anterior, a sincronização é feita pelos semáforos F e E que
indicam se o buffer está cheio ou vazio, respectivamente. Já a exclusão
mútua é realizada com o semáforo X
• Caso vários processos estejam esperando num mesmo semáforo, não está
definido qual deles será reativado pela operação V(S)
– Isto permite uma liberdade que o projetista pode usar para incluir um critério
de escalonamento mais adequado para sua aplicação. O único requisito é que
este critério seja justo
• Ao contrário de eventos, as operações com semáforos são comutativas,
tornando os programas menos suscetíveis a dependência de velocidade
induzidas por erros de programação

7-49


 Semáforos (6)
• Semáforos, assim como eventos e todas as primitivas de baixo nível, têm
uma séria desvantagem
– A conexão entre um recurso qualquer (ou condição) a uma operação de
semáforo é apenas uma convenção
– O esquecimento da chamada a uma destas primitivas pode ser desastroso

• Uma vantagem é que semáforos podem ser usados para implementar
exclusão mútua e comunicação
• Em algumas arquiteturas, os semáforos são implementados como
instruções de máquina dado ao seu baixo nível de abstração

7-50


 Mensagens (1)
• Spin Locks, eventos e semáforos não são apropriados para sistemas
distribuídos nos quais os processos executam em rede, sem compartilhamento
de memória
– A rede provê um serviço de comunicação que suporta a interação entre processos
por meio da troca de mensagens
 A troca de mensagens também pode ser usada como a base para interação entre
processos num sistema de memória compartilhada
» Tem a desvantagem de possuir uma sobrecarga maior, quando comparado com outras
primitivas, como os semáforos

– O envio de mensagens pressupõe um canal que pode levar uma mensagens de um
processo para outro
 O canal pode ser identificado por uma fila de mensagens (buffer) e dever permitir a
comunicação entre um número arbitrário de transmissores e receptores

7-51

 Mensagens (2)
– Quando um canal é implícito, suporta apenas a comunicação um-para-um, com o
transmissor devendo saber a identificação do receptor
– Este canal pode suportar a
 Comunicação em apenas uma direção (simplex)
 Comunicação em ambas as direções (duplex)
– As operações primitivas sobre canais incluem:
 connect um processo a um canal
 disconnect um processo de um canal

 send uma mensagem através de um canal

 receive uma mensagem de um canal ou espera por sua chegada

 test pela existência de uma mensagem de entrada num canal

– Uma mensagem pode ser formada por cópia dos dados do transmissor (mais usados em
sistemas distribuídos) ou por uma referência a dados compartilhados (mais usados em
sistemas de memória compartilhada)

7-52


 Chamada remota de procedimentos – RPC
• Numa RPC (Remote Procedure Call), o ambiente em tempo de execução determina
o site onde o procedimento chamado está e se comunica sincronamente com o site
para chamá-lo
– Oferece uma abstração para comunicação via mensagens, facilitando a programação e o
entendimento do código

• O site que tem este procedimento pode, quando do recebimento da chamada remota,
criar um processo para executá-la
• Alternativamente, um processo servidor no site pode receber todas as chamadas
remotas e atendê-las
• Esta escolha é feita com base no custo relativo da criação do processo em relação a
comunicação e também pelo grau de concorrência desejado

7-53

Abstrações para controle da concorrência (1)

 Objetivam organizar os programas concorrentes assim como
outras abstrações já estudadas organizam os programas
seqüenciais
• Regiões Críticas Condicionais

• Monitores

• Rendezvous

 Construções de alto nível que simplificam o desenvolvimento e o
entendimento de programas concorrentes

7-54


 Regiões críticas condicionais (1)
• Uma região crítica condicional é um comando composto que provê, tanto
exclusão mútua, quanto comunicação
– A idéia chave é que cada variável a ser compartilhada entre processos seja
declarada como tal

– Pseudo código em Ada v é a variável compartilhada
– region v do

C
O subcomando C é a seção crítica relativa à
end region;
variável v, que só pode ser acessada dentro de uma
seção crítica condicional – ou seja – o acesso
exclusivo a ela fica assegurado automaticamente
7-55



• Dentro da região crítica condicional, o await command

await E;

bloqueia o processo até que a condição E (que acessa a variável v) resulte

em true

– Enquanto espera bloqueado, o processo libera o uso exclusivo da

variável compartilhada, mas quando retoma a execução, a

exclusividade é assegurada

7-56


• Exemplo: implementação de buffer limitado
– type Message_Buffer is
shared record
size : Integer range 0 .. capacity;
front, rear : Integer range 1 .. capacity;
items : array (1 .. capacity) of Message;
end record;

procedure send_message (item : in Message; procedure receive_message (item : out Message;
buffer : in out Message_Buffer) is buffer : in out Message_Buffer) is
begin
begin region buffer do
region buffer do await buffer.size > 0;
await buffer.size < capacity; buffer.size := buffer.size - 1;
buffer.size := buffer.size + 1; item := buffer.items(buffer.front);
buffer.rear := buffer.rear mod buffer.front := buffer.front mod
capacity + 1; capacity + 1;
buffer.items(buffer.rear) := item; end region;
end region; end receive_message;
end send_message;
7-57


• Regiões críticas condicionais descrevem as interações entre os processos com
bastante clareza e simplicidade
– Exclusão mútua e comunicação sem variáveis auxiliares

– Exclusão mútua garantida em tempo de compilação

– Transmissão de condições é automática e implícita

– Recepção é simples e comuta com a transmissão

• Aumentam a clareza dos programas concorrentes, embora o comando await E
seja bastante custoso, já que é implementado em termos de um loop que
repetidamente testa E

7-58


 Monitores (1)
• Um monitor é um tipo de pacote que combina encapsulação com exclusão mútua
e sincronização
– Pascal concorrente (Brinch Hansen, 1977) e Módula (Wirth, 1977)
influenciaram linguagens baseadas em Pascal, que passaram a usar monitores
para estruturar a concorrência
• Os monitores de Módula asseguram a exclusão mútua para as operações de um
tipo abstrato de dados
– Diferente das regiões críticas condicionais, os monitores não suportam sinalização
automática
– Um tipo signal predefinido é fornecido com as operações send e wait

7-59


 Monitores (2)
– Cada variável signal declarada é na realidade uma fila de processos esperando
uma permissão para continuar a execução dentro do monitor

– A operação wait bloqueia um processo e coloca-o na fila de processos
correspondente da variável signal

– Enquanto fica esperando pelo signal, o processo libera o uso exclusivo do
monitor

– A operação send desbloqueia o processo na frente da fila de processos esperando
da variável signal correspondente

– Quando retoma a execução da operação, ganha o uso exclusivo do monitor

7-60

 Monitores (3)
• Exemplo: implementação de buffer limitado em Módula
– INTERFACE MODULE BufferMonitor;
DEFINE sendMessage, receiveMessage; (* public *)
TYPE MessageBuffer =
RECORD
size : 0.. capacity;
front, rear : 1 .. capacity;
items : ARRAY 1 .. capacity OF Message
END;
VAR buffer : MessageBuffer; nonfull, nonempty : signal;

PROCEDURE sendMessage (item : Message); PROCEDURE receive Message(VAR item : Message);
BEGIN BEGIN
IF buffer.size = capacity THEN IF buffer.size = 0 THEN
wait(nonfull); wait(nonempty);
buffer.size := buffer.size + 1; buffer.size := buffer.size - 1;
buffer.rear := buffer.rear MOD item := buffer.items[buffer.front];

capacity + 1; buffer.front := buffer.front MOD

buffer.items[buffer.rear] := item; capacity + 1;
send(nonfull)
send(nonempty)
END; END; 7-61


 Monitores (4)

• Como semáforos e eventos, o signal de monitores é associado a condições

apenas por uma convenção que deve ser respeitada na lógica do monitor

– Mais eficiente que await, embora menos simples e legível, exigindo mais

trabalho para o programador e mais oportunidades de erros

7-62

Abstrações para controle da
concorrência (10)
 Rendezvous – encontro – (1)
• Baseia-se na interação entre processos apenas através de comunicação
síncrona não bufferizada – o rendezvous
– Cada processo executa um comando indicando o desejo de se comunicar com o
outro
– Cada processo fica bloqueado até que o outro alcance o ponto de rendezvous

– Quando ambos estão prontos, uma mensagem é copiada de emissor para o
receptor, então, ambos são desbloqueados e continuam sua execução
independentemente
– Baseia-se na notação CSP (Communicating Sequential Processes), desenvolvida
por Hoare (1978)

7-63

Abstrações para controle da
concorrência (11)
 Rendezvous (2)

7-64

10.concurrency

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Semelhante a 10.concurrency

Semelhante a 10.concurrency (20)

10.concurrency