Notas de aula - Sistemas Operacionais

Captulo 7 Sincroni zao e Comuni cao entre processos

1. Introduo
Com o surgi mento dos si stemas mul ti programvei s, passou a ser
poss vel estruturar apl i caes de manei ra que partes di ferentes do
cdi go do programa pudessem executar concorrentemente,
acarr etando as.. .
Apl icaes concorrentes: execuo cooper ati va de ml ti pl os
processos ou threads, que tr abal ham em uma mesma tarefa na busca
de um resul tado comum.
Num SO mul ti programvel de ni co UCP os processos al ternam sua
execuo segundo cri tri os de escal onamento estabel eci dos pel o SO
(par al el i smo).
Num SO de ml ti pl os UCP a possi bi l i dade do paral el i smo na execuo
de i nstrues d mui to mai s vantagens.
Processos de apl i caes concorrentes compar ti l ham r ecursos do
si stema (como arqui vos, r egi stros, di sposi ti vos de E\S, memri a).
O compar ti l hamento de recur sos entr e processos pode acarretar
si tuaes i ndesej vei s capazes at de comprometer a execuo das
apl i caes.
Par a evi tar esse probl ema, os processos concorr entes devem ter suas
execues sincroni zadas, a par ti r de mecani smos ofer eci dos pel o SO
com o objeti vo de gar anti r o processamento correto dos programas.

2. Apli caes concorrentes

Em uma apl i cao concorrente necessri o que processos se
comuni quem entr e si . Esta comuni cao pode ser i mpl ementada
atravs de di versos mecani smos, como vari vei s compar ti l hadas na
memri a pri nci pal ou trocas de mensagens. Por i sso i mportante
haver si ncroni zao entr e estes processos.
Os mecani smos que garantem a comuni cao entr e os processos
concorrentes e o acesso a recursos comparti l hados so chamados
MECANISMOS DE SINCRONIZAO.
No projeto do SO mul ti programvel fundamental a i mpl ementao
deste mecani smo par a garanti r a i ntegri dade e a confi abi l i dade na
execuo de apl i caes concorrentes. (tambm val e par a
subprocessos e thr eads).

Ex.: 2 processos concorrentes comparti l ham um buffer para trocar
i nformaes atravs de operaes de gr avao e l ei tura. Neste
exempl o um processo s poder gr avar dados no buffer caso este no
esteja chei o. Da mesma forma, um processo s poder l er dados
ar mazenados no buffer caso haj a al gum dado a ser l i do. Em ambas as
si tuaes, os processos dever o aguardar at que o buffer estej a
pronto (para ser l i do ou par a ser gravado).



3. Especi fi cao de concorrncia

Concorrnci a em progr amas, so as partes de um programa que
devem ser executadas concorrentemente.
1 notao de especi fi cao de concorr nci a (fork e joi n):
O programa A comea a ser executado e ao encontrar o comando
FORK, faz com que sej a cri ado um outro processo para a execuo do
programa B concorrentemente ao programa A.
O comando JOIN permi te que o programa A si ncroni ze-se com B, ou
seja, quando o programa A encontr ar o comando JOIN s conti nuar a
ser processado aps o trmi no da execuo do programa B.



2 notao de especi fi cao de concorrncia (parbegin parend):
Programa abai xo real i za o cl cul o da expresso ari tmti ca
x:= sqrt (1024) + (35,4*0,23) (302/7)


2 notao de especi fi cao de concorrnci a (parbegi n par end):
Os comandos de atri bui o si tuados entre PARBEGIN e PAREND so
executados concorrentemente.
O cl cul o fi nal de X s poder ser r eal i zado quando todas as vari vei s
dentro da estrutura ti verem si do cal cul adas.

4. Problemas no Compart ilhamento de Recursos
Ex.1: compar ti l hamento de um arqui vo em di sco

Atual i za sal do bancri o de um cl i ente aps um l anamento de dbi to
ou crdi to no arqui vo da conta corrente ARQ_CONTAS. Neste arqui vo
so armazenados os sal dos de todos os correnti stas. O programa l o
regi stro do cl i ente no arqui vo (REG_CLI), l o val or a ser deposi tado
ou reti rado (VALOR_DEP_RET) e em segui da atual i za o sal do no
ARQ_CONTAS.

Ex.: comparti l hamento de um arqui vo em di sco
Se 2 funci onri os do banco esti ver em atual i zando o sal do do mesmo
cl i ente si mul taneamente, onde 1 func est debi tando e outro est
cr edi tando. Tendo este REG_CLI comparti l hado, i ndependente de qual
processo (deb ou crd) atual i ze pri mei ro o sal do no arqui vo, o dado
gravado estar i nconsi stente.


5. Excluso Mtua

A sol uo mai s si mpl es para evi tar probl emas de comparti l hamento
apr esentados no i tem anteri or i mpedi r que 2 ou mai s processos
acessem o mesmo recurso si mul taneamente.
Par a i sso, enquanto um processo esti ver acessando um recurso, todos
os demai s processos que quei ram acessar o mesmo recur so dever o
aguardar o trmi no da uti l i zao do recurso. Isso a excl uso mtua.
A excl uso mtua deve af etar somente os processos concorrentes
quando um del es esti ver f azendo acesso ao recurso comparti l hado.
A parte do cdi go do programa onde fei to o acesso ao recurso
compar ti l hado chamada regi o cr ti ca.

A parte do cdi go do programa onde fei to o acesso ao recurso
compar ti l hado chamada regi o cr ti ca.
Se for poss vel evi tar que 2 processos entrem em suas r egi es cr ti cas
si mul taneamente, ou sej a, se for gar anti da a execuo mutuamente
excl usi va das r egi es cr ti cas, os probl emas decorrentes do
compar ti l hamento sero evi tados.
Usando mecani smo de protocol os de entr ada e sa da de acesso
regi o cr ti ca, podemos i mpl ementar a excl uso mtua.




Ex. da conta corrente: sempr e que o processo A for atual i zar o sal do
de um REG_CLI, antes de l er o regi stro o acesso excl usi vo ao arqui vo
deve ser gar anti do, atr avs do protocol o de entr ada da sua r egi o
cr ti ca. O protocol o i ndi ca se h ou no al gum processo acessando o
recurso.
Caso o recurso estej a l i vre o processo A pode entr ar na r egi o cr ti ca
e r eal i zar a atual i zao. Durante este per odo, caso o processo B
tente acessar o arqui vo, o protocol o de entrada f az com que esse
processo per manea em esper a at que o processo A termi ne o acesso
ao recurso (atual i zao do arqui vo sal do do cl i ente).
Quando o processo A ter mi nar a execuo da sua regi o cr ti ca,
dever si nal i zar aos demai s processos concorrentes que o acesso ao
recurso foi concl u do atravs do protocol o de sa da, l i ber ando assi m o
recurso par a os concorrentes.

1 Si tuao indesejada:
STARVATION (esper a i ndefi ni da): quando um processo nunca
consegue executar sua r egi o cr ti ca e conseqentemente acessar o
recurso comparti l hado.
Quando um recur so l i berado o SO sel eci ona (al eatori amente ou por
ex. atr avs de cri tri os de pri ori dades) dentr e os processos em
esper a qual del es dever acessar tal recurso, podendo ocorrer a o
STARVATION.
Pode ser sol uci onado cri ando fi l as de pedi dos de al ocao par a cada
recurso uti l i zando FIFO Fi rst i n Fi rst out (pri mei ro que chega o
pri mei ro que sai ).
Sempre que um processo sol i ci ta um r ecurso, o pedi do col ocado no
fi m da fi l a. Quando o recur so l i berado, o SO sel eci ona o pri mei ro
processo em esper a da fi l a.
2 Si tuao indesejada :
Um processo fora da sua regi o cr ti ca i mpede que outros processos
entr em nas suas prpri as regi es cr ti cas: no caso dessa si tuao, um
recurso estari a l i vre por m al ocado a um processo. Com i sso vri os
processos estari am sendo i mpedi dos de utili zar tal recurso,
reduzindo o grau de comparti lhamento

Excluso Mtua solues de HARDWARE

Desabi l i tao de Interrupes: fazer com que o processo desabi l i te as
i nterrupes antes de entr ar em sua r egi o cr ti ca e as r eabi l i te aps
dei xar a sua r egi o cr ti ca. Como a mudana de contexto de processos
s pode ser r eal i zada atravs de i nterrupes, o processo que as
desabi l i tou ter acesso excl usi vo garanti do.
Ex.: LIMITAES: a mul ti programao pode fi car seri amente
comprometi da, j que a concorrnci a entr e processos tem como base
o uso de i nterrupes OU um processo que no reabi l i te a i nterrupo
causando probl emas grav ssi mos no SO.


2) Instruo TEST-and-SET: l uma vari vel , ar mazena seu contedo
em uma outra r ea e atri bui um novo val or mesma vari vel . Essa
i nstruo executada sem i nterrupo (i ndi vi s vel ). Gar anti ndo assi m
que 2 processos no mani pul em uma var i vel compar ti l hada ao
mesmo tempo, possi bi l i tando a excl uso mtua.
O uso do Test-and-Set ofer ece al gumas vantagens como a
si mpl i ci dade de i mpl ementao da excl uso mtua em ml ti pl as
regi es cr ti cas e o uso da sol uo em arqui teturas com ml ti pl os
processador es.
A pri nci pal desvantagem a possi bi l i dade do starvati on (espera
i ndefi ni da), poi s a sel eo do processo para o acesso ao recurso
arbi trri a.



5. Excluso Mtua solues de SOFTWARE

Di versos al gori tmos foram propostos na tentati va de i mpl ementar a
excl uso mtua atr avs de sol ues por softwar e.
As pri mei ras sol ues tr atavam apenas da excl uso mtua par a 2
processos e i ni ci al mente apr esentavam al guns probl emas.
De forma evol uti va, procurou-se o desenvol vi mento de sol ues
defi ni ti vas par a a excl uso mtua de N processos, atr avs de vri os
al gori tmos:

6. Sincroni zao Condi cional
uma si tuao em que o acesso ao recurso comparti l hado exi ge a
si ncroni zao de processos vi ncul ada a uma condi o de acesso.
Um r ecur so pode no se encontrar PRONTO par a uso devi do a uma
condi o espec fi ca. Nesse caso o processo que desej a acess-l o
dever per manecer bl oqueado at que o recurso fi que di spon vel .
Ex.: comuni cao entre 2 processos atravs de operaes de gr avao
e l ei tura num buffer, onde processos geram i nformaes (processos
produtores) uti l i zadas por outros processos (processos
consumi dores).
Nessa comuni cao, enquanto um processo grava dados num buffer , o
outro l dados, concorrentemente.

Os processos envol vi dos devem estar si ncroni zados a uma vari vel de
condi o, de forma que um processo no tente gravar dados em um
buffer chei o ou real i zar uma l ei tura em um buffer vazi o.
Ex.: o recurso compar ti l hado um buffer de tamanho X e sendo
control ado por uma vari vel CONT. Sempre que a vari vel CONT=0,
si gni fi ca que o buffer est vazi o e o processo consumi dor deve
per manecer aguardando at que se gr ave um dado. Quando a vari vel
CONT=X, si gni fi ca que o buffer est chei o e o processo produtor deve
aguardar a l ei tura de um novo dado. Nessa sol uo, a tar ef a de
col ocar e r eti r ar dados do buffer r eal i zada, r especti vamente, pel as
operaes de gr avao e l ei tura do buffer, executados de forma
mutuamente excl usi va.
Resol ve a si ncroni zao condi ci onal mas a esper a ocupada se f az
presente, sendo sol uci onada pel os semforos e moni tores.

7. SEMFOROS
Um semforo uma vari vel i ntei ra, no-negati va, que s pode ser
mani pul ada por 2 i nstrues: DOWN e UP.
DOWN e UP so i ndi vi s vei s (no podem ser i nterrompi das), onde UP
i ncrementa 1 uni dade ao val or do semforo enquanto DOWN
decrementa 1 uni dade vari vel .
Por defi ni o, val ores negati vos no podem ser atri bu dos a um
semforo, a i nstruo DOWN executada em um semforo com val or 0
faz com que o processo entre em estado de espera. Podem ser
cl assi fi cados em:
SEMFOROS BINRIOS: s podem assumi r val ores zero ou um.
SEMFOROS CONTADORES: podem assumi r qual quer val or i ntei ro
POSITIVO al m do zero.

7.1- Excluso mtua com Semforos

Tem como vantagem a no-ocorrnci a da esper a ocupada.
As i nstrues DOWN e UP funci onam como protocol os de Entrada e
Sa da par a que um processo possa entr ar em sua regi o cr ti ca.
O semforo fi ca associ ado a um r ecurso compar ti l hado, i ndi cando
quando o recurso est sendo acessado por um dos processos
concorrentes.
O val or do semforo=1 i ndi ca que nenhum processo est uti l i zando o
recurso enquanto semforo=0 i ndi ca que o recurso est em uso.

Sempre que desej a entrar na sua regi o cr ti ca, um processo executa
uma i nstruo DOWN.
Se um semforo=1, este val or decrementado e o processo que
sol i ci tou a oper ao pode executar as i nstrues da sua regi o cr ti ca.
Se um semforo=0, o processo fi ca i mpedi do do acesso,
per manecendo em estado de ESPERA e consequentemente no
ger ando overhead (processamento em excesso) no UCP.
O processo que est acessando o recurso, ao sai r da sua r egi o
cr ti ca, executa uma i nstruo UP, i ncrementando o val or do semforo
e l i berando o acesso ao recurso.

Sempre que desej a entrar na sua regi o cr ti ca, um processo executa
uma i nstruo DOWN.
Se um semforo=1, este val or decrementado e o processo que
sol i ci tou a oper ao pode executar as i nstrues da sua regi o cr ti ca.
Se um semforo=0, o processo fi ca i mpedi do do acesso,
per manecendo em estado de ESPERA e consequentemente no
ger ando overhead (processamento em excesso) no UCP.
O processo que est acessando o recurso, ao sai r da sua r egi o
cr ti ca, executa uma i nstruo UP, i ncrementando o val or do semforo
e l i berando o acesso ao recurso.

Se um ou mai s processos esti ver em esperando pel o uso do recur so
(DOWN pendentes), o SO sel eci onar por ordem na fi l a de esper a
associ ada ao recur so e al ter ar o seu estado de pronto.



7.2- Sincroni zao Condi cional com Semforos
Ex.: quando um processo sol i ci ta uma oper ao de E\S. O pedi do faz
com que o processo execute a i nstruo DOWN no semforo associ ado
ao evento e fi que no estado de ESPERA, at que a operao E\S sej a
compl etada. Quando a oper ao ter mi na, a roti na executa um UP no
semforo, l i berando o processo do estado de espera.
SEMFOROS CONTADORES so bastante tei s quando apl i cados em
probl emas de si ncroni zao condi ci onal onde h processos
concorrentes al ocando recursos do mesmo ti po (pool de recursos).
O semforo i ni ci al i zado com um nmero total de recursos do pool e,
sempr e que um processo desej a al ocar um recurso, executa um
DOWN, subtr ai ndo 1 ao nmero de recursos di spon vei s. Quando
l i bera 1 recurso faz um UP. Se o semforo contador = 0, si gni fi ca
que no h + recursos di spon vei s e o processo deve aguardar at
que l i bere al gum.

7.3- Problema dos Filsofos

H uma mesa com 5 pr atos, 5 garfos onde os fi l sofos podem sentar ,
comer e pensar .
Toda vez que um fi l sofo pr a de pensar e desej a comer necessri o
que el e uti l i ze 2 garfos, posi ci onados sua di rei ta e sua esquerda.
Se todos os fi l sofos esti verem segur ando 1 garfo, nenhum fi l sofo
consegui r comer, ger ando um DEADLOCK (bl oquei o). Par a sol uci onar
o deadl ock, temos al gumas sol ues:
a) per mi ti r que apenas 4 fi l sofos sentem mesa si mul taneamente;
b) permi ti r que um fi l sofo pegue um garfo apenas se o outro garfo
esti ver di spon vel ;
c) permi ti r que um fi l sofo mpar pegue o pri mei ro o seu garfo da
esquer da e depoi s o da di rei ta, enquanto um fi l sofo par pegue
pri mei ro o garfo da di rei ta e depoi s o garfo da esquerda.

7.4- Problema do Barbei ro

Um bar bei ro recebe cl i entes par a cortar o cabel o. Na barbeari a h 1
cadei ra de barbei ro e apenas 5 cadei ras par a cl i entes esper ar em.
Quando um cl i ente chega, caso o barbei ro estej a tr abal hando, el e
senta se houver cadei ra vazi a, ou vai embora se todas as cadei ras
esti ver em ocupadas.
No caso do barbei ro no ter cl i entes para atender , el e mesmo senta
na cadei ra e dorme at que um novo cl i ente apar ea.

8- MONITORES
So mecani smos de si ncroni zao estruturada de al to n vel que
tornam mai s si mpl es o desenvol vi mento de apl i caes concorrentes.
O MONITOR formado por procedi mentos e vari vei s encapsul adas
dentro de um mdul o, onde somente um processo pode estar
executando um dos procedi mentos do moni tor em um determi nado
i nstante.
Toda vez que um processo faz uma chamada a um desses
procedi mentos, o moni tor veri fi ca se j exi ste um outro processo
executando al gum procedi mento do moni tor.
Caso exi sta, o processo fi car aguardando a sua vez em uma fi l a de
entr ada.

As vari vei s gl obai s de um moni tor so vi s vei s apenas aos
procedi mentos da sua estrutur a, sendo i nacess vei s fora do contexto
do moni tor.
Toda a i ni ci al i zao das vari vei s real i zada por um bl oco de
comandos do moni tor, sendo executado apenas uma vez, na ati vao
do programa onde est decl ar ado o moni tor



9- Troca de Mensagens
um mecani smo de comuni cao e si ncroni zao entr e os processos.
O SO possui um subsi stema de msg que suporta este mecani smo sem
que haj a necessi dade de uso de vari vei s comparti l hadas.
Par a que haj a comuni cao entre os processos deve exi sti r um canal
de comuni cao, podendo esse mei o ser um buffer ou um l i nk de uma
rede de computador es.
Processos cooperati vos podem fazer uso de um buffer para trocar
msgs atr avs de 2 roti nas: SEND (transmi ssor) ou RECEIVE
(receptor).
necessri a a si ncroni zao entr e os 2 processos (send e recei ve) j
que uma msg somente pode ser tratada por um processo aps ter si do
recebi da, ou o envi o da msg s pode ser uma condi o para a
conti nui dade de execuo de um processo.

SEND permi te envi ar msg para um processo r eceptor, enquanto
RECEIVE possi bi l i ta o recebi mento da msg envi ada por um
transmi ssor.


Comunicao di reta: exi ge que ao envi ar ou receber uma msg, o
processo enderece expl i ci tamente o nome do processo receptor ou
transmi ssor. Uma car acter sti ca deste ti po de comuni cao s
per mi ti r a troca de msg entr e 2 processos. Um probl ema a
necessi dade da especi fi cao do nome dos processos envol vi dos na
troca de mgs. No caso de mudana de nome, o cdi go do programa
deve ser al ter ado e recompi l ado.

Comunicao indi reta: uti l i za uma rea compar ti l hada, onde as
msgs podem ser col ocadas pel o processo tr ansmi ssor e reti radas pel o
processo receptor. Esse ti po de buffer conheci do como MAILBOX ou
PORT e suas car acter sti cas como ID e capaci dade de ar mazenamento
de mensagens so defi ni das no momento de cri ao.
Vri os processos podem estar associ ados a mai l box, e os par metros
dos procedi mentos SEND e RECEIVE passar a ser nomes de mai l boxes
e no de processos

Esquemas para implementar Comunicao indi reta:
Gar anti r que um processo, ao envi ar uma mensagem, permanea
esper ando at que o processo r eceptor a l ei a. Na mesma condi o,
um processo ao tentar receber uma msg ai nda no envi ada, deve
per manecer aguardando at o envi o da mesma. Um probl ema que a
execuo de processos fi ca l i mi tada ao tempo de processamento no
tratamento das mensagens.
Permi ti r que o processo tr ansmi ssor no permanea bl oqueado
aguardando a l ei tura da mensagem pel o processo receptor. Neste
caso, um processo envi ar mensagens para di versos desti natri os to
l ogo sej a poss vel .
Forma ass ncrona de comuni cao, onde nem o processo receptor nem
o transmi ssor permanecem aguardando o envi o ou recebi mento de
mensagens. H necessi dade de buffers par a ar mazenar as mensagens
e mecani smos de si ncroni zao que permi tam ao processo i denti fi car
se a mensagem j foi envi ada ou recebi da, aumentando a efi ci nci as
das apl i caes concorr entes.

10- DEADLOCK
quando um processo aguarda por um r ecurso que nunca estar
di spon vel ou um evento que no ocorrer. Isso conseqnci a do
compar ti l hamento de r ecursos, como di sposi ti vos, arqui vos, regi stros
entr e processos concorrentes em que a excl uso mtua exi gi da.
O probl ema do deadl ock torna-se cada vez mai s freqente e cr ti co na
medi da em que os SOs evol uem no senti do de i mpl ementar o
par al el i smo de forma i ntensi va e per mi ti r al ocao di nmi ca de um
nmero mai or de recursos.


PA obtm acesso excl usi vo de R1 assi m como PB de R2. Durante o
processamento, PA necessi ta de R2 par a prossegui r. Como R2 est
al ocado a PB, PA fi car aguardando que o recurso seja l i berado. Em
segui da PB necessi ta de R1 e da mesma forma, fi car aguardando at
que PA l i bere o recurso.
As 4 Condies para ocorrer DEADLOCK
1- EXCLUSO MTUA: cada r ecurso s pode ser al ocado a um ni co
processo em um determi nado i nstante;
2- ESPERA POR RECURSO: um processo, al em dos recursos j
al ocados, pode estar esperando por outros recursos;
3- NO-PREEMPO: um recurso no pode ser l i berado de um
processo s porque outros processos desej am o mesmo recurso;
4- ESPERA CIRCULAR: um processo pode ter de esperar por um
recurso al ocado a outro processo e vi ce-ver sa.
DEADLOCK h em qual quer SO mul ti programvel , contudo as sol ues
i mpl ementadas devem consi der ar o ti po do SO e o i mpacto em seu
desempenho. Ex.: um deadl ock em um SO de tempo real de uma usi na
nucl ear no pode ser tr atado da mesma forma dos deadl ocks de SOs
de tempo comparti l hado comum.
10.1- Preveno de DEADLOCK
preci so garanti r que uma das 4 condi es necessri as no ocorra.
A ausnci a da EXCLUSO MTUA acaba com o deadl ock, poi s nenhum
processo ter que esper ar par a ter acesso a um r ecurso, mesmo que
este estej a sendo uti l i zado por outro processo. Contudo surgi r
probl emas de i nconsi stnci as.
Par a evi tar a ESPERA POR RECURSO, processos que j possuam
recursos garanti dos no devem r equi si tar novos recur sos. Uma
manei ra de i mpl ementar i sso que antes do i n ci o da execuo, um
processo deve pr-al ocar todos os r ecursos necessri os. Sendo que
TODOS estes r ecur sos devem estar di spon vei s para i ni ci ar a
execuo, seno nenhum recurso ser al ocado e o processo fi car
aguardando. Isso pode ger ar desperd ci o vi sto que um recurso poder
fi car al ocado por grande tempo sendo apenas uti l i zado por um
pequeno momento.

A NO-PREEMPO pode ser evi tada quando permi ti do que um
recurso sej a r eti rado de um processo caso outro processo necessi te
desse r ecur so. A l i berao de recur sos j gar anti dos por um processo
pode ocasi onar sri os probl emas, podendo at i mpedi r a conti nui dade
de execuo de um processo e tambm acarretar starvati on (espera
i ndefi ni da), poi s aps garanti r os recur sos necessri os a sua
execuo, um processo pode ter que l i ber-l os sem concl ui r seu
processamento.
Evi tando a ESPERA CIRCULAR, i mpl ementando a forar o processo a
ter apenas um r ecurso por vez. Caso o processo necessi te de outro
recurso, o recurso j al ocado deve ser l i berado. Esta condi o
restri ngi ri a mui to o grau de comparti l hamento e o processamento dos
programas.


10.2- Deteco de DEADLOCK
a deter mi nao da exi stnci a da si tuao de deadl ock, permi ti ndo
i denti fi car os r ecursos e os processos envol vi dos.
Os SOs devem manter estruturas de dados capazes de i denti fi car cada
recurso do si stema, o processo que o est al ocando e os processos
que esto esper a da l i berao do recurso.
Toda vez que um recurso l i berado ou al ocado, essas i nformaes
devem ser atual i zadas.
Os al gori tmos que i mpl ementam esse mecani smo veri fi cam se h
esper a ci rcul ar, percorrendo toda a estr utura sempr e que um processo
sol i ci ta um r ecur so e el e no pode ser i medi atamente garanti do.
Sendo que esse tempo de busca (veri fi cao) pode vari ar dependendo
do ti po do SO, ex.: SO tempo comparti l hado o tempo de busca pode
ser mai or, sem comprometer o desempenho e confi abi l i dade; SO
tempo r eal i sso no pode ocorrer.
Aps a deteco do deadl ock o SO dever corri gi r o probl ema.
Ger al mente usam el i mi nar um ou mai s processos envol vi dos no
deadl ock e desal ocam os recur sos j gar anti dos por el es.
A el i mi nao dos processos envol vi dos, consequentemente, a
l i berao de seus recursos podem no ser si mpl es, dependendo do
ti po do recurso envol vi do.
Os processos el i mi nados no tem como ser r ecuper ados, porem outros
processos que antes estavam em deadl ock, podero concl ui r sua
execuo.
A escol ha do processo a ser el i mi nado fei ta al eatri a ou por
pri ori dades, podendo consumi r mui to tempo do processador.
Pode-se tambm l i berar al guns recursos al ocados aos processos par a
outros processos, at que o ci cl o de espera termi ne. Par a que i sso
seja efi ci ente, necessri o que o SO suspenda um processo, l i bere os
recursos e posteri ormente r etorne ao processo do ponto onde parou
seu processamento, chamado ROLLBACK.

Exerc cios

1. Defi na o que uma oper ao concorrente e d um exempl o de sua
uti l i zao.
2. O que uma excl uso ml ti pl a e como i mpl ementada?
3. O que star vati on e como podemos resol ver este probl ema?
4. Qual o probl ema com a sol uo que desabi l i ta as i nterrupes
par a habi l i tar a excl uso mtua?
5. O que esper a ocupada e qual seu probl ema?
6. Expl i que o que si ncroni zao condi ci onal e d um exempl o de sua
uti l i zao.
7. Expl i que o que so semforos e d doi s exempl os de sua uti l i zao:
um para a sol uo de excl uso mtua e outro para si ncroni zao
condi ci onal
8. O que deadl ock, quai s as condi es par a obt-l o e quai s as
sol ues poss vei s?
9. Em uma apl i cao concorrente que control a o sal do bancri o em
contas correntes, doi s processos compar ti l ham uma r egi o da
memri a onde esto armazenados os sal dos dos cl i entes A e B.
Os processos executam concorrentemente os segui ntes passos:

Processo 1 Cliente A Processo 2 Cliente B
/* saque em A */
1a. x:= sal do_do_cl i ente_A;
1b. x:= x 200;
1c. sal do_do_cl i ente_A:= x;
/* deposi to em B */
1d. x:= sal do_do_cl i ente_B;
1e. x:= x + 100;
1f. sal do_do_cl i ente_B := x;
/* saque em B */
2a. y:= sal do_do_cl i ente_B;
2b. y:= y 100;
2c. sal do_do_cl i ente_B:= y;
/* deposi to em B */
2d. y:= sal do_do_cl i ente_B;
2e. y:= y + 2100;
2f. sal do_do_cl i ente_B := y;

Supondo que os val ores dos sal dos A e B sej am, r especti vamente 500
e 900 antes dos processos serem executados pede-se:
a) Quai s os val ores corretos esperados para os cl i entes A e B aps o
trmi no da execuo dos processos?
b) Quai s os val ores fi nai s dos sal dos dos cl i entes se a seqnci a
temporal de execuo for 1, 2, 1b, 2b, 1c, 2c, 1d, 2d, 1e, 2e, 1f,
2f?
c) Uti l i zando semforos proponha uma sol uo que garanta a
i ntegri dade dos sal dos e permi ta o mai or comparti l hamento poss vel
dos recursos entr e os processos, no se esquecendo da especi fi cao
da i ni ci al i zao dos semforos.