10 Concurrency

7-1
10
Concorrncia
Por que concorrncia?.
Programas e processos.
Problemas com a concorrncia.
Interaes de processos.
Primitivas de concorrncia
Abstraes para controle da concorrncia
7-2
Por que concorrncia? (1)
A concorrncia foi inicialmente introduzida nos
computadores com o objetivo de melhorar o desempenho
Realizao de E/S e operaes da CPU em simultneo, que
acarretou o surgimento da programao concorrente
A programao concorrente ficou muito complexa para o
programador de aplicaes
Restringiu-se basicamente aos sistemas operacionais, que seriam os
arqutipos dos programas concorrentes
7-3
Os sistemas de multiprogramao objetivam maximizar o
uso dos recursos atravs da execuo de dois ou mais jobs
concorrentemente
Sistemas de multiacesso ou servidores estendem a
multiprogramao, permitindo que vrios jobs executem,
cada um em benefcio de um usurio remoto
Sistemas de multiprocessador esto presentes em
computadores que vrias CPUs operando simultaneamente
na execuo de jobs que compartilham uma memria
principal
7-4
Sistemas distribudos consistem de vrios computadores
que no apenas operam independentemente, mas que
tambm se intercomunicam eficientemente
A medida que a velocidade das CPU atingem limites
tecnolgicos, ganhos futuros em desempenho dependem de
uma melhor explorao da concorrncia
A concorrncia em linguagem de programao necessria
para permitir a modelagem mais precisa dos aspectos
concorrentes do mundo real
Desenvolvimento de arquiteturas de computadores novas e
altamente concorrentes
7-5
Programas e Processos (1)
Um processo seqencial um conjunto totalmente ordenado
de passos, cada passo sendo uma mudana de estado em
algum componente de um sistema de computao
Um programa seqencial especifica as possveis mudanas
de estado de um processo seqencial, as quais ocorrem numa
ordem determinada pelas estruturas de controle do programa
Um programa concorrente especifica as possveis
mudanas de estados de dois ou mais processos seqenciais
Nenhuma ordem naturalmente definida entre as mudanas de
estados de um processo em relao a mudanas de estados de
quaisquer outros processos
Dizemos que estes processos so executados concorrentemente,
podendo at mesmo serem executados simultaneamente
7-6
Programas e Processos (2)
O exemplo de um processo seqencial a execuo de um
programa numa linguagem como Pascal ou C
Os eventos de um processo como este correspondem atualizao das
variveis do programa
Tais eventos so totalmente ordenados pelas regras de seqenciamento da
linguagem, que definem como o controle transferido de um comando
para outro
Por causa da total ordenao dos eventos, pode-se associar
passagem do tempo fsico as mudanas de estado de um
programa seqencial
Mudanas de estado de baixo nvel podem no ser totalmente ordenadas
no tempo, porm como no so observveis pelo programador e como
no afetam o resultado final, no so consideradas relevantes
7-7
Problemas com a concorrncia (1)
O que faz os programas concorrentes serem diferentes dos
programas seqenciais?
No-determinismo (1)
Um programa determinstico aquele que segue uma seqncia de
passos que pode ser prevista caso saibamos seus dados de entrada
Programas seqenciais corretos so sempre determinsticos
Logo, seu comportamento pode ser completamente reproduzido, tornando
praticvel a verificao de programas por meio de testes
Existem construes que introduzem alguma imprevisibilidade em
programas seqenciais como:
Comandos colaterais
Comandos condicionais no determinsticos
Avaliao colateral de subexpresses, onde uma destas subexpresses pode
provocar efeitos colaterais em outra
7-8
No-determinismo (2)
Em cada um destes casos
O processador da linguagem livre para escolher a ordem de
execuo
O comportamento do programa poder ser diferente com
processadores distintos, mas certamente ser o mesmo num
processador de linguagem especfico
Logo o comportamento do programa poder ser reproduzido
Um programa concorrente, por outro lado, verdadeiramente no-
determinstico
A ordem de execuo dos passos imprevisvel, assim como o
resultado final, mesmo num processador de linguagem especfico
Em geral, deseja-se escrever programas efetivamente
determinsticos, isto , um programa cujo resultado global seja
previsvel
7-9
No-determinismo (3)
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 irreproduzvel
Erros de programao concorrente so dos mais difceis de se
diagnosticar
A pesquisa de meios para preveni-los uma grande motivao na rea
de programao concorrente

7-10
Dependncia de Velocidade (1)
Um programa seqencial independente de velocidade porque
sua correo no depende da velocidade com que executado
Um programa concorrente, em geral, dependente de velocidade,
visto que suas sadas podem depender da velocidade relativa de
execuo dos processos que o compem
Como conseqncia, pequenas flutuaes na velocidade dos
processadores e dos dispositivos de E/S podem levar ao no-
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 condio de corrida (race condition)
7-11
Exemplo: condio de corrida
Suponha que dois processos P e Q atualizam a mesma varivel s do
tipo String
In P: s := "ABCD";
In Q: s := "EFGH";
Se P completa a atribuio antes de Q comear a atribuio, o valor
final de s "EFGH"
Se Q completa a atribuio antes de P comear a atribuio, 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-12
Imagine-se caos do problema anterior com mltiplos processos e
variveis
Um dos objetivos da programao concorrente prevenir este pesadelo
Uso de variveis atmicas aquelas que s podem ser inspecionadas ou
atualizadas como um todo
Em Java, referncia a objetos e variveis de tipos primitivos diferentes de long
e double so sempre atmicas
Em Ada, qualquer varivel pode ser declarada atmica com a clusula
pragma atomic(v);, embora o compilador seja livre para rejeit-la
Entretanto, tais medidas esto longe de ser uma soluo completa
7-13
Deadlock (1)
Deadlock o bloqueio permanente de um conjunto de processos que, ou
esto competindo por recursos, ou esto competindo para se comunicar uns
com os outros
O deadlock pode ocorrer num sistema de processos e recursos, se e
somente se, as seguintes condies existirem todas juntas
Excluso mtua: os processos podem ter acesso exclusivo aos recursos
Aquisio incremental: os processos continuam a prender recursos
previamente alocados, enquanto esperam que a requisio de um novo recurso
seja atendida
No preempo: recursos no 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 prximo processo
no ciclo
7-14
Deadlock (2)
Vrios enfoques podem ser empregados para solucionar o problema do
deadlock
Ignorar o deadlock e caso ele acontea, resolver o problema manualmente pela
interferncia do operador do sistema, destruindo alguns processos ou
reinicializando todo o sistema
Outra opo detectar o deadlock e ento recuperar-se dele automaticamente,
de modo que o sistema como um todo possa continuar funcionando
Prevenir o deadlock pela eliminao de uma ou mais condies necessrias
sua ocorrncia
Eliminao da aquisio incremental de processos ou tudo ou nada
Eliminao da espera circular imposio de uma ordem de aquisio de recursos
Fazer com que os escalonadores do sistema evitem ativamente o deadlock pela
determinao antecipada dos processos que se pretende alocar
Algoritmo do banqueiro
7-15
Starvation (1)
Um sistema concorrente tem a propriedade de avano finito se
houver a garantia de que todo processo avanar em algum perodo
suficientemente grande de tempo (mas finito)
Para atender a esta condio o sistema deve
Ser livre de deadlock
Ter um escalonamento justo
Escalonamento a alocao de recursos para processos no tempo, tendo por
meta algum objetivo, como um tempo de resposta adequado ou a alta utilizao
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-16
Starvation (2)
Usa-se o termo starvation quando um processo fica esperando
indefinidamente para executar por causa de um escalonamento
injusto
Uma situao 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-17
Interaes de Processos (1)
A notao C; K especifica a composio seqencial dos
comandos C e K
A notao C, K especifica a composio colateral dos
comandos C e K
A diferena entre os dois que na composio seqencial
todas as aes de C devem ser encerradas antes que qualquer
ao de K comece; enquanto na composio colateral as aes
de C e K podem ser intercaladas arbitrariamente
Nenhuma das notaes admite a possibilidade dos comandos
C e K serem executados simultaneamente
7-18
Para isto, usa-se o comando paralelo B || C, que a
composio concorrente dos comandos B e C
Especifica que dois ou mais comandos podem ser executados
concorrentemente
B || C no requer a execuo simultnea dos comandos B e C, mas
permite isto
B || C tambm permite a execuo colateral e a execuo seqencial
dos comandos B e C como casos particulares de concorrncia
Programas concorrentes se distinguem dos seqenciais no
apenas pela presena da composio concorrente, mas
tambm pela presena de operaes que causam interaes
entre processos, que pode ser de vrios tipos
7-19
Processos independentes (1)
Os comandos B e C so independentes se nenhum passo de B pode
afetar o comportamento de qualquer passo de C e vice-versa
Se B e C so independentes, segue que a composio seqencial B; C
equivalente a composio seqencial C; B
Tambm pode-se concluir que B; C, C; B e C, K so equivalentes a
C || K quando C e K so independentes
Logo, segue que a composio concorrente de processos independentes
determinstica
Este um resultado importante porque
Prover a base para sistemas servidores de multiacesso, que podem
executar muitos jobs pela multiprogramao de um ou mais processadores
Sendo os jobs independentes, os usurios no precisam tomar precaues
especiais por conta da concorrncia
7-20
Processos independentes (2)
Infelizmente, no decidvel, em geral, se os comandos B e C so
realmente independentes
Entretanto, uma condio suficiente para independncia que nenhum
comando possa atualizar uma varivel que outro comando inspeciona
ou atualiza
Embora possa ser verificado, em princpio, em tempo de compilao,
deve-se empregar uma definio abrangente de varivel, como qualquer
componente do sistema cujo estado possa ser alterado
7-21
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 seqncia B
1
;B
2
;B
3
e C a seqncia C
1
;C
2
;C
3

Os subcomandos B
1
, B
3
, C
1
e C
3
so independentes , ou seja, nenhuma deles
usa o recurso r
B
2
e C
2
requerem acesso exclusivo ao recurso r e no devem executar
simultaneamente nem sua execuo se sobrepor no tempo
B
2
e C
2
so chamados de sees crticas com respeito ao recurso r
7-22
B || C deveria ser executado numa das seguintes maneiras
...; B
2
; ...; C
2
; ...
...; C
2
; ...; B
2
; ...
mas no como
...; B
2
|| C; ...
Ento, B || C tem dois possveis resultados, que so exatamente os
resultados das seqncias B; C e C; B, respectivamente
Qual destes resultados realmente ocorre depender das velocidades relativas
com que B e C so executados e isto no previsvel em geral
Caso o efeito de uma seo crtica dependa do estado do recurso quando ele
adquirido e se a seo muda o estado do recurso, ento o sistema B || C no-
determinstico em geral
Um programa concorrente possui a propriedade de safety (segurana)
se suas sees crticas nunca se sobrepem no tempo
seguro no sentido de que todos os comando que ele aplica sobre um
recurso ter o seu efeito seqencial normal
7-23
Exemplo: No determinismo apesar da excluso mtua
Suponha que dois processos P e Q atualizam a varivel i do tipo Integer,
atmica e com valor inicial 0
Os comandos de atribuio de P e Q esto em excluso mtua, um em
relao ao outro
In P: i := i + 1;
In Q: i := 2 * i;
Existe corrida (race) entre P e Q, mas os dois nicos possveis resultados
em i so 1 (Q executa a atribuio antes de P) ou 2 (P executa a atribuio
antes de Q)
que se chama de no determinismo delimitado: o resultado no previsvel,
mas pertence a um conjunto conhecido e fixo de sadas, todas igualmente
aceitveis
7-24
Processos comunicantes (1)
Sejam os comandos B e C como vistos anteriormente
Existe comunicao de B para C caso B
2
produza dados que C
2
consuma,
de modo que B
2
termine antes de C
2
comear
Neste caso, B || C tem o mesmo resultado que B; C
Um pipeline ocorre quando existe uma encadeamento de processos, cada um
consumindo a sada 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 comunicao em
ambas as direes
Isto torna os possveis resultados de B || C muito mais numerosos e
Fora a impor uma severa disciplina nas formas de intercomunicao
permitidas, caso se deseje preservar o gerncia intelectual dos programas
7-25
Primitivas de Concorrncia (1)
Conjunto de operaes de baixo nvel que afeta a
concorrncia atravs de sua criao, controle e destruio
Fundamental para entender as construes de alto nvel das
linguagens de programao concorrente
Tipos de processos (1)
Processos convencionais havyweight: a execuo de um programa
para o qual o sistema operacional prover um espao de
endereamento, a alocao de memria principal e tambm o
compartilhamento da CPU e de outros recursos
Sobrecarga substancial para criao de processos e tambm na troca de
contexto de um processo para o outro pelo sistema operacional
7-26
Tipos de processos (2)
Processos thread lightweight: um fluxo de controle atravs de um
programa, mas que no 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-27
Criao e controle de processos (1)
As operaes primitivas relativas processos so as seguintes
create um processo filho novo e inativo
load o cdigo de programa a ser executado por um processo
start a execuo de um processo
suspend a execuo de um processo (temporariamente)
resume a execuo de um processo (suspenso)
permitir que um processo stop ele mesmo ao fim de sua execuo
permitir que seu criador wait por pelo processo para parar
destroy um processo parado, liberando quaisquer recursos alocado
para ele
7-28
sempre conveniente combinar as operaes create, load e start
numa nica operao, em geral chamada fork e combinar wait e
destroy numa nica operao chamada join
fork sempre definido de modo que o programa do processo filho
uma cpia exata do programa do processo pai
No sistema operacional UNIX, a operao fork uma funo sem
parmetros que retorna um inteiro
No processo pai este inteiro a identificao do novo processo filho criado,
enquanto no processo filho, este inteiro zero
As primitivas so bem gerais, permitindo a criao de quaisquer
sistemas de processos concorrentes ativos
Tm a desvantagem de no revelar com clareza o fluxo do controle do
programa, que se desenvolve dinamicamente
7-29
Exemplo: forking um novo processo no UNIX
child_id := fork;
if child_id = 0 then
programa filho
else
continua programa pai
O UNIX no tem operao join. Um processo destrudo
automaticamente quando termina
Alm de operaes para criao e terminao de processos, preciso
operaes que permitam uma comunicao e competio pacfica
entre os mesmos
7-30
Para permitir que as sees crticas de processos competidores sejam
disjuntas no tempo, as operaes primitivas acquire(r) e relinquish(r)
so 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 detm
o recurso r, r se torna livre para ser realocado e os processos que esto
esperando por r so reescalonados
Um desses processos pega r exclusivamente, completando sua operao
acquire(r)
7-31
Um par de operaes similares suportam a comunicao entre
processos:
Um processo transmissor chama a operao transmit(c), que envia uma
mensagem notificando a ocorrncia de um condio c
c pode ser, por exemplo, "operao de E/S terminada" ou "CPU 2 foi
reiniciada"
O processo receptor chama a operao receive(c), que o bloqueia at que
a condio c ocorra
A operao transmit pode se comunicar com um processo receptor
especfico ou ser na forma de difuso (broadcast), tornando a
transmisso disponvel a qualquer receptor interesado
Caso no haja um receptor apto no momento da transmisso, ela pode se
perder ou pode ser armazenada o projeto das primitivas determina o
tipo de comportamento
7-32
Interrupes
Uma interrupo , na prtica, uma chamada de procedimento invisvel
inserido aleatoriamente em algum ponto do programa!
Usadas em operaes de entrada e sada, para indicar que uma
operao autnoma de E/S terminou
Se o dispositivo de E/S for visto como um processo externo, a
interrupo pode tratada como um mecanismo para comunicao entre
processos
Estendendo este conceito, pode-se permitir que um processo (interno)
interrompa outro comando kill no UNIX
Trocas de contextos, em geral, so implementadas com interrupes
Combina nveis de prioridade e possibilidade de inabilitao de
interrupes
7-33
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 atravs de
repetidos testes num flag que indica se o recurso est livre
A primeira pessoa a conseguir este feito (um algoritmo que
implementasse excluso mtua) foi o matemtico Dekker em 1968 num
trabalho apresentado por E. Dijkstra
O trabalho apresenta uma srie de tentativas incorretas de implementao,
que ilustram as dificuldades encontradas pelo programador para lidar com
acesso exclusivo a variveis compartilhadas
Assume a serializao justa nas operaes de acesso memria realizadas
concorrentemente pela CPU/interface de memria
7-34
Srie de tentativas que culminaram no algoritmo de Dekker (1)
Assume-se a existncia de dois processos 1 e 2, cada um executando um
programa com a seguinte forma (self sendo 1 ou 2)

repeat
cdigo no crtico para processo self;
acquire(r);
seo crtica para processo self;
relinquish(r);
exit when processo self estiver finalizado;
until processo self ser terminado

com um padro cclico de acesso ao recurso protegido r
7-35
A primeira usar uma varivel turn, inicializada com 1 ou 2, que indica
quais dos dois processos tem permisso para entrar na sua seo crtica.
Cada processo self implementa as primitivas de excluso 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
seo crtica. Entretanto, uma soluo muito rgida uma vez que impe
uma ordem alternada de entrada dos processos na seo crtica
7-36
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
seo crtica. Ambos os componentes de claimed so 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 aps ter
encontrado claimed[other] = false e antes de fazer claimed[self] = true.
Neste momento especfico 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 sees
crticas concorrentemente. Logo, a excluso mtua no est garantida
7-37
Uma maneira de consertar tal problema seria modificar a operao acquire(r)
como segue

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

Mas, nesta situao, um problema surge caso o processo 1 (digamos) esteja
num ponto aps fazer claimed[self] = true e antes de entrar no loop. Isso
permite que o processo 2 faa o mesmo, ficando ambos os processos
reclamando uso do recurso compartilhado indefinidamente e nunca mais
conseguiro entrar na sua seo crtica
7-38
Corrige-se essa falha permitindo que cada processo retire sua reclamao
temporariamente durante o loop, dando a oportunidade ao outro processo para
prosseguir
acquire(r):
while claimed(other) loop
claimed(self) := false;
end
Esta soluo funciona com sucesso na maior parte das situaes, 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
soluo falha porque dependente de velocidade
7-39
Algoritmo de Dekker para excluso mtua
Combina as melhores caractersticas das tentativas anteriores. Usa as variveis
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 difcil de generalizar para mais
de dois processos preservando a justia. O algoritmo de Peterson, descoberto
em 1981 est livre destes problemas
7-40
Algoritmo de Peterson para excluso mtua

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

relinquish(r):
7-41
O cdigo baseado em spin locks pode apresentar problemas
A otimizao de loops pode pr-alocar variveis em registradores, de tal forma
que a sua atualizao num processo no percebida pelos outros
Pode-se prevenir isto em C, C++ e Java declarando a varivel com o modificador
volatile
Em Java, variveis long e double declaradas volteis passam a ser tambm atmicas, assim como as
demais variveis de tipos primitivos, porm, no h como garantir a volatilidade dos elementos de um
array em Java!
Em Ada, uma varivel declarada como atmica automaticamente voltil, que
tambm pode ser declarada voltil explicitamente
pragma volatile(v);
pragma volatile_componentes(a);
7-42
Spin locks so 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 funes de bloqueio que fazem um processo suspender a si mesmo
Funes de bloqueio podem provocar uma regresso infinita se chamadas pelo
escalonador do sistema operacional para implementao da excluso mtua suas
prprias variveis
Tais algoritmos podem precisar de instrues especiais que permitem a atualizao
atmica de mais de uma posio de memria
A memria cache pode ser um problemas em sistemas multiprocessados!
O algoritmo de Simpson, de 1990, um desses algoritmos de espera-livre, e no usa
bloqueios ou spin locks
7-43
Eventos (1)
Um evento representa uma categoria de mudanas de estados, cuja
ocorrncia deve ser comunicada para um conjunto de processos
Implementado pelas operaes 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
prxima ocorrncia de um evento de categoria e
A operao event-signal(e) faz com que todos os processos que esto bloqueados
por e fiquem prontos para executar novamente

7-44
Eventos (2)
Exemplo: spin lock com bloqueio
Implementao de uma verso com bloqueio da operao 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-45
Eventos (3)
Considerado como primitivas de comunicao, eventos tm desvantagens
As operaes wait e signal no so comutativas, sendo sujeitas a dependncia
de velocidade
A operao event-signal(e) desperta todos os processos bloqueados no
evento e, de modo que esta implementao de transmit interpretada como
broadcasting (difuso)
Eventos no so teis para excluso mtua, devendo-se ter um suporte em
separado para isto (como spin locks ou interrupes)
Apesar das desvantagens, o uso de eventos combinados com interrupes proveu a
base original para bem sucedida gerncia de processos na famlia de sistemas
operacionais UNIX
7-46
Semforos (1)
Um semforo uma varivel S do tipo inteiro e um grupo associado de
processos esperando para executar, sobre a qual apenas duas operaes
atmicas podem ser realizadas, alm de uma operao de incializao
P(S): if S 1 then
S := S 1
else o processo em execuo se coloca no grupo de processos associados a S que esto
esperando para executar e libera a CPU
end if;
V(S): if fila de processos de S no vazia then
remova um processo que est esperando e o coloque disponvel para executar
else
S := S + 1
end if;
7-47
Shared Variable
var S: semaphore := 1;

Process i

loop
...
P(S);
Acessa seo crtica
V(S);
...
end loop;

Process j

loop
...
P(S);
Acessa seo crtica
V(S);
...
end loop;
Semforos (2)
Exemplo: implementao de excluso mtua
7-48
Shared Variable
var X: semaphore := 1;
F,E: semaphore := 0,1;
buffer: Char;

Process Producer
var nextChar: Char;

loop
GetChar(nextChar);
P(E);
P(X);
buffer := nextChar;
V(X);
V(F);
end loop;

Process Consumer
var nextChar: Char;

loop
P(F);
P(X);
nextChar := buffer;
V(X);
V(E);
PutChar(nextChar);
end loop;
Semforos (3)
Semforos so comutativos, sendo adequados para implementao de
sincronizao exemplo para o problema produtor/consumidor
7-49
Semforos (5)
No exemplo anterior, a sincronizao feita pelos semforos F e E que
indicam se o buffer est cheio ou vazio, respectivamente. J a excluso
mtua realizada com o semforo X
Caso vrios processos estejam esperando num mesmo semforo, no est
definido qual deles ser reativado pela operao V(S)
Isto permite uma liberdade que o projetista pode usar para incluir um critrio
de escalonamento mais adequado para sua aplicao. O nico requisito que
este critrio seja justo
Ao contrrio de eventos, as operaes com semforos so comutativas,
tornando os programas menos suscetveis a dependncia de velocidade
induzidas por erros de programao
7-50
Semforos (6)
Semforos, assim como eventos e todas as primitivas de baixo nvel, tm
uma sria desvantagem
A conexo entre um recurso qualquer (ou condio) a uma operao de
semforo apenas uma conveno
O esquecimento da chamada a uma destas primitivas pode ser desastroso
Uma vantagem que semforos podem ser usados para implementar
excluso mtua e comunicao
Em algumas arquiteturas, os semforos so implementados como instrues
de mquina dado ao seu baixo nvel de abstrao
7-51
Mensagens (1)
Spin Locks, eventos e semforos no so apropriados para sistemas
distribudos nos quais os processos executam em rede, sem
compartilhamento de memria
A rede prov um servio de comunicao que suporta a interao entre
processos por meio da troca de mensagens
A troca de mensagens tambm pode ser usada como a base para interao entre
processos num sistema de memria compartilhada
Tem a desvantagem de possuir uma sobrecarga maior, quando comparado com outras
primitivas, como os semforos
O envio de mensagens pressupe 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
comunicao entre um nmero arbitrrio de transmissores e receptores
7-52
Mensagens (2)
Quando um canal implcito, suporta apenas a comunicao um-para-um, com
o transmissor devendo saber a identificao do receptor
Este canal pode suportar a
Comunicao em apenas uma direo (simplex)
Comunicao em ambas as direes (duplex)
As operaes primitivas sobre canais incluem:
connect um processo a um canal
disconnect um processo de um canal
send uma mensagem atravs de um canal
receive uma mensagem de um canal ou espera por sua chegada
test pela existncia de uma mensagem de entrada num canal
Uma mensagem pode ser formada por cpia dos dados do transmissor (mais
usados em sistemas distribudos) ou por uma referncia a dados compartilhados
(mais usados em sistemas de memria compartilhada)
7-53
Chamada remota de procedimentos RPC
Numa RPC (Remote Procedure Call), o ambiente em tempo de execuo
determina o site onde o procedimento chamado est e se comunica
sincronamente com o site para cham-lo
Oferece uma abstrao para comunicao via mensagens, facilitando a
programao e o entendimento do cdigo
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 criao do processo em
relao a comunicao e tambm pelo grau de concorrncia desejado
7-54
Abstraes para controle da concorrncia (1)
Objetivam organizar os programas concorrentes assim como
outras abstraes j estudadas organizam os programas
seqenciais
Regies Crticas Condicionais
Monitores
Rendezvous
Construes de alto nvel que simplificam o desenvolvimento e o
entendimento de programas concorrentes
7-55
Regies crticas condicionais (1)
Uma regio crtica condicional um comando composto que prov, tanto
excluso mtua, quanto comunicao
A idia chave que cada varivel a ser compartilhada entre processos seja
declarada como tal
Pseudo cdigo em Ada
region v do
C
end region;
v a varivel compartilhada
O subcomando C a seo crtica relativa
varivel v, que s pode ser acessada dentro de uma
seo crtica condicional ou seja o acesso
exclusivo a ela fica assegurado automaticamente
7-56
Dentro da regio crtica condicional, o await command
await E;
bloqueia o processo at que a condio E (que acessa a varivel v) resulte
em true
Enquanto espera bloqueado, o processo libera o uso exclusivo da
varivel compartilhada, mas quando retoma a execuo, a
exclusividade assegurada
7-57
Exemplo: implementao 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;
buffer : in out Message_Buffer) is
begin
region buffer do
await buffer.size < capacity;
buffer.size := buffer.size + 1;
buffer.rear := buffer.rear mod
capacity + 1;
buffer.items(buffer.rear) := item;
end region;
end send_message;

procedure receive_message (item : out Message;
buffer : in out Message_Buffer) is
begin
region buffer do
await buffer.size > 0;
buffer.size := buffer.size - 1;
item := buffer.items(buffer.front);
buffer.front := buffer.front mod
capacity + 1;
end region;
end receive_message;
7-58
Regies crticas condicionais descrevem as interaes entre os processos
com bastante clareza e simplicidade
Excluso mtua e comunicao sem variveis auxiliares
Excluso mtua garantida em tempo de compilao
Transmisso de condies automtica e implcita
Recepo simples e comuta com a transmisso
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-59
Monitores (1)
Um monitor um tipo de pacote que combina encapsulao com excluso
mtua e sincronizao
Pascal concorrente (Brinch Hansen, 1977) e Mdula (Wirth, 1977)
influenciaram linguagens baseadas em Pascal, que passaram a usar
monitores para estruturar a concorrncia
Os monitores de Mdula asseguram a excluso mtua para as operaes de
um tipo abstrato de dados
Diferente das regies crticas condicionais, os monitores no suportam
sinalizao automtica
Um tipo signal predefinido fornecido com as operaes send e wait
7-60
Monitores (2)
Cada varivel signal declarada na realidade uma fila de processos esperando
uma permisso para continuar a execuo dentro do monitor
A operao wait bloqueia um processo e coloca-o na fila de processos
correspondente da varivel signal
Enquanto fica esperando pelo signal, o processo libera o uso exclusivo do
monitor
A operao send desbloqueia o processo na frente da fila de processos
esperando da varivel signal correspondente
Quando retoma a execuo da operao, ganha o uso exclusivo do monitor
7-61
Monitores (3)
Exemplo: implementao de buffer limitado em Mdula
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);
BEGIN
IF buffer.size = capacity THEN
wait(nonfull);
buffer.size := buffer.size + 1;
buffer.rear := buffer.rear MOD
capacity + 1;
buffer.items[buffer.rear] := item;
send(nonempty)
END;
PROCEDURE receive Message(VAR item : Message);
BEGIN
IF buffer.size = 0 THEN
wait(nonempty);
buffer.size := buffer.size - 1;
item := buffer.items[buffer.front];
buffer.front := buffer.front MOD
capacity + 1;
send(nonfull)
END;
7-62
Monitores (4)
Como semforos e eventos, o signal de monitores associado a condies
apenas por uma conveno que deve ser respeitada na lgica do monitor
Mais eficiente que await, embora menos simples e legvel, exigindo mais
trabalho para o programador e mais oportunidades de erros
7-63
Abstraes para controle da
concorrncia (10)
Rendezvous encontro (1)
Baseia-se na interao entre processos apenas atravs de comunicao
sncrona no 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 esto prontos, uma mensagem copiada de emissor para o
receptor, ento, ambos so desbloqueados e continuam sua execuo
independentemente
Baseia-se na notao CSP (Communicating Sequential Processes),
desenvolvida por Hoare (1978)
7-64
Abstraes para controle da
concorrncia (11)
Rendezvous (2)

10 Concurrency

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

10 Concurrency

Cargado por

Copyright:

Formatos disponibles

7-1

También podría gustarte