Simulador de Deadlocks

Lucas Santana Lellis

1
, Danilo Augusto Dias Carvalho
1
1
Instituto de Ci encia e Tecnologia Universidade Federal de S ao Paulo (UNIFESP)
Rua Talim, 330, S ao Jos e dos Campos, S ao Paulo, CEP 12231-280
lellis@unifesp.br, dan.adc@hotmail.com
1. Introduc ao
Segundo [Silberschatz et al. 2010]. O Deadlock acontece quando v arios processos
competem por dados recursos, de forma que ambos dependam de recursos ocupados
mutuamente. Nesta ocasi ao, n ao h a como recuperar ambos os processos naturalmente,
permanecendo parados indenidamente.
O tratamento de deadlocks e um problema bastante controverso. Uma vez que este tipo
de ocorr encia e pouco frequente, prefere-se permitir que tais problemas ocorram ao inv es
de elaborar estrat egias de prevenc ao. Uma forma de representar um estado de deadlock
e quando dois carros, vindo de direc oes diferentes, competem pela passagem em uma
ponte de unica via.
Se ambos entrarem na ponte simultaneamente, um precisar a sair do caminho do outro,
caso contr ario n ao conseguir ao sair do lugar. Este problema se agrava ao haver o encontro
de uma la de carros vindo de cada lado. O que diculta muito o possvel tratamento de
deadlock.
2. Objetivos
Este trabalho tem o objetivo de demonstrar, atrav es de simulac oes did aticas, diferentes
tratamentos de deadlock para o problema da ponte. Demonstrando e avaliando diferentes
tipos de sem aforos de prevenc ao de Dead Locks, permitindo comparar a eci encia de
cada tratamento neste caso especco.
3. Fundamentos
Segundo [Silberschatz et al. 2010], um deadlock impede que os processos terminem sua
execuc ao, interferindo tamb em no desempenho, comprometendo os recursos do computa-
dor, como a mem oria. Ele ocorrer a se as quatro condic oes seguintes ocorrerem simultane-
amente:
Exclus ao m utua: Pelo menos um recurso deve permanecer em estado n ao-
compartilhado. Ou seja, nenhum outro processo pode utiliz a-lo at e o processo
atual liberar a sua utilizac ao.
Posse e espera: Deve haver um processo que esteja mantendo um recurso, mas
esteja parado, esperando por um recurso bloqueado por outros processos.
N ao-preempc ao: Os recursos s o podem ser liberados pelo processo ap os terminar
suas tarefas.
Espera circular: Existe uma cadeia de processos, cada um esperando por um
recurso bloqueado pelo pr oximo elemento da cadeia.
O caso dos carros e o caso mais simples de deadlock, e como se um processo impedisse o
outro de prosseguir, ou seja, nem um dos dois carros conseguem prosseguir, pois o outro
est a bloqueando o caminho, e com a presenca de mais carros, vai se acumulando uma
cadeia carros sendo bloqueados pelo carro ` a sua frente. O recurso, neste caso e a ponte,
ou pista, e o estado de deadlock pode ser tratado de tr es formas principais:
Podemos prevenir a ocorr encia de um deadlock, de forma que nunca ocorra.
Podemos deixar que ocorra o deadlock, detectar sua ocorr encia e em seguida,
recuperar o sistema.
Podemos ignorar o problema, e considerar que eles t em uma probabilidade muito
baixa de ocorrer para ocupar recursos de mem oria e processamento para trat a-los.
3.1. Prevenc ao de Deadlocks
A prevenc ao de deadlocks exige que o sistema gerencie os recursos e requisic oes de forma
que este estado nunca ocorra. Desta forma, o programa precisa interagir com o S.O. para
efetuar suas requisic oes para um dado recurso. Enquanto n ao for atendido, seu processo
e interrompido de forma que n ao interra no desempenho do sistema em geral.
Como o estado de deadlock s o existe quando ocorrem as quatro condic oes j a apresen-
tadas, podemos tentar evitar pelo menos uma delas, de forma que o deadlock n ao ocorra.
No caso dos carros, a utilizac ao de um sem aforo temporizado pode ser considerada uma
forma de prevenc ao de deadlock, uma vez que evitamos que dois processos ( carros ) com-
pitam por um recurso especco ( ponte ) indenidamente, de forma que cada processo
tem a sua vez de utilizar tal recurso.
O primeiro algoritmo trata-se ent ao de um sem aforo temporizado, com tempos denidos
para os sinais verde, amarelo e vermelho, chamado por n os de classical Semaphore, ou
seja, um sem aforo comum de tr ansito. Como n ao h a conhecimento do tamanho dos uxos
vindo de cada um dos lados, n ao e possvel evitar que a pista seja reservada, sem mesmo
haver carros vindo desta direc ao.
Uma das soluc ao empregadas foi criar um segundo algoritmo de sem aforo que funciona
de forma semelhante ao sem aforo comum, mas com um conhecimento da proporc ao de
carros vinda de cada lado da pista. Desta forma, al em de evitar que o sem aforo que
aberta para um lado da pista sem carros, ele tamb em dar a prioridade para o lado com
mais veculos, aumentando assim o uxo e o n umero de processos completos.
3.2. Recuperac ao de Deadlocks
A recuperac ao de deadlocks normalmente acontece abortando os processos, de forma que
se encerre o ciclo de de deadlock. Este processo tamb em e custoso, por em ainda pode
ser melhor do que perder recursos para processos parados. O tratamento pode ocorrer
abortando todos os processos parados de uma s o vez, o que pode ser danoso, fazendo
com que precise ser refeito um servico trabalhoso, por parte do usu ario, ou de trabalho
computacional. Ou tamb em, pode-se abortar um processo de cada vez at e que o ciclo
de deadlock seja desfeito, sendo um processo custoso, j a que a cada operac ao, deve-se
detectar se os processos continuam impedidos.
No caso dos carros, como n ao se pode deletar um carro no mundo real, ou explodi-lo, o
que seria muito custoso de v arias formas, optamos por uma opc ao mais simples, em que
os carros de um dos lados da pista d ao r e para que os carros na direc ao contr aria possam
usufruir da ponte.
3.3. N ao tratamento
O tratamento, seja por prevenc ao ou por recuperac ao pode ser um processo muito tra-
balhoso, e bastante custoso computacionalmente, diante da real probabilidade de ocorrer.
Visto que os programas est ao cada vez mais inteligentes e os pr oprios programadores
podem tamb em implementar suas pr oprias t ecnicas de prevenc ao, evitando, de alguma
forma, que haja uma espera indenida por um dado recurso.
Em contrapartida, o caso especco estudado neste trabalho apresenta uma alta taxa de
ocorr encia de deadlocks, dependendo da proporc ao de carros vindo de cada lado da pista.
Como mostraremos neste trabalho, a ocorr encia deste problema, neste caso especco, e
quase certa, sendo necess ario reconsiderar se n ao vale a pena utilizarmos algum m etodo
de tratamento.
4. Implementac ao
O projeto foi desenvolvido na linguagem Java, atrav es da animac ao de imagens (sprites)
de autom oveis e sem aforos. Sua implementac ao est a separada em tr es pacotes, chamados
graphics, logics e objects. Que ser ao mais amplamente apresentrados nas seguintes
sec oes. No diagrama UML da gura 1 podemos ver o diagrama completo da interac ao
entre as classes.
Figure 1. Diagrama UML de todo o projeto
4.1. Graphics
O pacote Graphics abriga classes relacionadas com a interface gr aca e a animac ao. bem
como e onde se localiza a main. Nela est ao contidas as classes AnimationBoard, Main-
Board e MovimentThread. O pacote pode ser visto no diagrama UML, da gura 2.
4.1.1. MainBoard
A classe MainBoard possui a main do programa, sendo tamb em a base da interface
gr aca. Respons avel por inicializar toda a interface, denindo os seus bot oes, frames
e suas localizac oes. Como visto na gura 2, al em da jFrame (interface gr aca), ela
guarda dentro de si um objeto da classe AnimationBoard, que propriamente controla
Figure 2. Diagrama UML do pacote Graphics
a animac ao, sendo atualizada constantemente em uma thread separada, da classe Ani-
mateThread. Os seus bot oes t em grande import ancia, pois chamam as ac oes de reiniciar
as simulac oes, e de alternar entre os diversos tipos de sem aforos.
4.1.2. AnimationBoard

E uma classe derivada de JPanel, sendo a peca fundamental da animac ao. Ela controla
as ac oes de atualizac ao e desenha todos os componentes da cena de acordo com as suas
coordenadas e imagens guardadas em seus interiores. Sua principal func ao e chamada de
paintComponents, que, em alto nvel, seria:
Atualiza tempo no trafc controller e sem aforos;
Desenha informac oes textuais, plano de fundo e sem aforos;
Percorre vetor desenhando carros vindo da esquerda para a direita;
Percorre vetor desenhando carros vindo da direita para a esquerda;
Atualiza estado do semaforo
Movimenta carros e verica colis oes atrav es do trafc Controller
Remove carros que j a percorreram todo o cen ario
Outra func ao importante e a restart que reinicia a simulac ao. Cujo algoritmo seria,
tamb em em alto nvel:
1. Verica se os valores de entrada s ao v alidos, caso contr ario, retorna a func ao
2. Reinicia o timer do sem aforo
3. Reinicia os contadores de processos completos
4. Reinicia controlador de tr afego
5. Ativa o gerador de carros
Al em destas, existem func oes respons aveis por substituir os sem aforos, e tamb em
por validar a entrada de texto inserida na interface gr aca.
4.1.3. AnimateThread
A classe AnimateThread deriva da classe Thread do Java, e tem a func ao de atualizar
a AnimationBoard em uma thread separada, com o benefcio de poder ser pausada, dimin-
uindo signicativamente o esforco da CPU. Sua func ao principal e chamada run, sua
implementac ao em Java e bem simples:
1 //Loop infinito atualiza a AnimationBoard contantemente
2 while(true){
3 //A funcao repaint, consequentemente chama a funcao
paintComponent
4 target.repaint();
5 //Processo e pausado de 5 em 5 ms
6 Thread.sleep(5);
7 }
4.2. Logics
O pacote Logics cont em as l ogicas chave da simulac ao, como o gerador de carros
trafcController, e os diferentes algoritmos de sem aforos, representados pela classe
SemaphoreController e suas derivadas. O diagrama UML da gura 3 mostra clara-
mente que n ao h a interac ao direta entre semaphoreController e trafcController.
4.2.1. trafcController
A classe trafcController tem a miss ao de guardar os carros, controlar a movimentac ao,
e gerar suas posic oes iniciais randomicamente, com um limite denido de carros que
podem ser instanciados de cada lado da ponte. Ela tamb em possibilita o c alculo dos
relat orios de durac ao e n umero de processos completos de cada lado da pista. Seu
construtor recebe como entrada o n umero de carros da esquerda e da direita, iniciando
tamb em um cron ometro, utilizado para calcular a quantidade de processos completos por
segundo.
Ela tamb em propaga comandos entre todos os carros, percorrendo os vetores ED e
DE, que representam, respectivamente, os uxos de carros vindo da esquerda, e da
direita, respectivamente, e chamando as func oes respons aveis por ativar ou desativas os
carros, ou a sua movimentac ao.
Uma das func oes principais e a movement, que recebe um fator de deslocamento
speed, e os sem aforos esquerdo e direito por refer encia, como pode ser visto nesta
implementac ao:
Como podemos inserir um valor speed para aumentar a velocidade de desloca-
mento, precisamos prever alguns problemas, como a possibilidade do carro n ao passar
a exatos 50 pixels de dist ancia do farol. Assim, adicionamos um fator de correc ao, um
intervalo em que o carro DEVE parar, caso o sem aforo esteja vermelho.
1 void movement(Semaphore lSem, Semaphore rSem, int speed ){
2 for(int i = 0; i < nCarrosDE; i++) {
3 if( rSem.needToWait() ) {
4 if( carrosDE[i].getX() < ( rSem.getX() + 50 ) ||
Figure 3. Diagrama UML do pacote Logics
5 carrosDE[i].getX() > ( rSem.getX() + 50 + speed ) ){
6 carrosDE[i].movement( -1
*
speed );
7 }
8 } else
9 carrosDE[i].movement( -1
*
speed );
10 }
11 //Acontece analogamente para carros ED
12 }
Outra func ao importante e a collisionDetection, respons avel por vericar as colis oes de
cada carro individualmente, comandando as ac oes de parar ou avancar. Uma funcionali-
dade extra foi adicionada para executar uma esp ecie de tratamento de DeadLock. Em que
os carros de uma das leiras d ao r e, todos ao mesmo tempo, para liberar a passagem dos
carros que vem no sentido contr ario. O processo acontece da seguinte forma:
Verica colis ao entre carros do mesmo sentido.
Se houver colis ao, o carro de tr as deve parar.
Verica colis ao entre carros de sentidos opostos.
Se houver colis ao frontal, os dois carros entram em estado de deadlock.
Por em, se o tratamento de dealock estiver ativado, aciona a r e para todos os carros
de um determinado lado do trafego.
Por ultimo, outra func ao importante e a generateRandomPositions, que possui uma
vers ao diferente para cada sentido, sendo a do uxo esquerdo chamada de generateRan-
domPositionED, e vice-versa, e sua implementac ao se d a da seguinte forma:
1. Gera um n umero aleat orio randomX menor que nCarrosED * 300
2. Posiciona carro no cen ario na coordenada ( -100 - randomX, 85 )
3. Verica se h a colis ao do novo carro com qualquer um dos carros existentes, caso
ocorra, retorna ao passo 1
O mesmo algoritmo e utilizado analogamente para posicionar os carros do uxo direito.
4.2.2. SemaphoreController
Esta e a classe principal do nosso experimento, dela derivamos os diferentes algoritmos
de sem aforos utilizados para gerenciar os uxos de carros. Seus atributos s ao impor-
tantssimos para a simulac ao, sendo armazenadas refer encias para os dois sem aforos, o
tempo de cada estado, o estado atual e o tempo decorrido desde que entrou no estado
atual.
Seu m etodo mais importante e abstrato, e e chamado de update, e nesta func ao que est a
o algoritmo de cada sem aforo. Al em disso, como pode se ver na gura 3, existem outras
func oes que podem ser utilizadas por todas as subclasses, como a func ao resetTimer, al em
das func oes setLGreen e semelhantes, que t em a func ao de trocar a cor dos sem aforos,
alterar o estado do controlador, e reiniciar o timer.
4.2.2.1 DisabledSemaphore
A classe disabledSemaphore e uma subclasse de semaphoreController. Embora n ao
altere os estados dos sem aforos, ele controla a animac ao do sem aforo, assim como um
sem aforo desativado, piscando a luz amarela intermitentemente. Sua func ao principal e a
update, e sua unica obrigac ao e animar o sem aforo, ligando e desligando a luz amarela.
Isso se d a da seguinte forma:
1 public void update() {
2 if( elapsedTime < 100 ){
3 left.setYellowLight();
4 right.setYellowLight();
5 }else if( elapsedTime < 200 ){
6 left.setBlackLight();
7 right.setBlackLight();
8 }else{
9 //Passados 200 ciclos, o contador e reiniciado
10 elapsedTime = 0;
11 }
12 }
4.2.2.2 ClassicalSemaphore
A classe ClassicalSemaphore representa o funcionamento de um sem aforo de tr ansito
comum, com tempos iguais para ambos os lados da ponte. A implementac ao de seu algo-
ritmo se d a na func ao update, onde e feita a troca entre os possveis estados, que podem
ser, sem aforo verde, amarelo, vermelho, ` a esquerda ou a direita, ou tamb em um estado
de espera ` a esquerda ou ` a direita. Este estado de espera e necess ario para permitir que os
carros do uxo anterior terminem seu percurso sobre a ponte, liberando assim, o acesso
para os carros do uxo seguinte.
Sua implementac ao depende completamente das vari aveis da sua classe m ae. Ela se ba-
seia num contador de tempo, que conta o tempo decorrido durante cada estado, e tamb em
dos estados, propriamente. Sua implementac ao e bem simples, por em bastante extensa,
mas de forma geral pode ser representada como:
Dene o estado atual atrav es de um switch.
Verica se o tempo decorrido j a passou o tempo denido para o estado atual.
Quando o resultado e verdadeiro, avanca para pr oximo estado, reiniciando o con-
tador.
Os estados acontecem na ordem: Verde Esq., Amarelo Esq., Vermelho Esq., Es-
pera Esq., Verde Dir., Amarelo Dir., Vermelho Dir., Espera Dir., Volta ao primeiro
estado.
4.2.2.3 PrioritySemaphore
Por m, a classe PrioritySemaphore se assemelha ` a um sem aforo cl assico, mas com a
possibilidade de dar maior prefer encia para o lado com o maior uxo de carros, sendo
capaz de manter o sem aforo sempre verde quando o uxo vem apenas de um lado.
Esta classe tem como diferencial a exist encia de dois atributos, lp e rp, que guardam,
respectivamente, a prioridade (proporc ao) de carros ` a esquerda e ` a direita. O c alculo de lp
e rp se baseia no n umero de carros ` a esquerda e ` a direita, armazenado no trafc controller,
assim, seu construtor possui como diferencial, receber uma referencia do controller, de
forma que o c alculo de lp e rp e feito da seguinte forma:
1 //tc == traffic controller
2 double total = tc.nCarrosED + tc.nCarrosDE;
3 lp = 2
*
( tc.nCarrosED / total );
4 rp = 2
*
( tc.nCarrosDE / total );
Al em disso, a condic ao inicial do sem aforo depende da proporc ao, que pode ser igual
a zero em um dos dois lados. Assim, as condic oes iniciais do sem aforo s ao obtidas da
seguinte forma:
1 if( lp == 0 ){ //Nao possui fluxo vindo da esquerda
2 setRGreen();
3 setLRed();
4 }else if( rp == 0 ){ //Nao possui fluxo vindo da direita
5 setLGreen();
6 setRRed();
7 }else{ //Possui fluxo em ambos os lados
8 setLGreen();
9 setRRed();
10 }
Como dito anteriormente, seu sem aforo e arbitrado de acordo com prioridade. Sua
implementac ao e muito semelhante ` a do sem aforo cl assico, por em, o tempo que o
sem aforo de cada um dos lados e proporcional ` a prioridade destes. Sendo possvel
otimizar o uxo de carros vindo de cada direc ao.
Sua implementac ao difere do classicalSemaphore nos seguintes trechos:
1 switch (state) {
2 case LGreen:
3 if( elapsedTime > greenTime
*
lp )
4 setLYellow();
5 break;
6 // Outros estados ...
7 case RGreen:
8 if( elapsedTime > greenTime
*
rp )
9 setRYellow();
10 break;
11 //...
12 }
4.3. Objects
O pacote Objects cont em classes importantes, que s ao manipuladas pelos controladores
do pacote logics, sendo estes as classes Car e Semaphore. Como pode-se ver no di-
agrama da gura 4, n ao h a relacionamento direto entre as classes Car e Semaphore,
pois s ao relacionadas atrav es de um mediador, que e trafcController. Esses elemen-
tos sozinhos n ao possuem funcionalidades aut onomas, sendo modicados manualmente
atrav es de seus respectivos controladores.
4.3.1. Car
A classe Car e utilizada para representar, independentemente, cada carro da simulac ao.
Ela guarda informac oes imprescindveis para a simulac ao, como a sua localizac ao na
cena, sua imagem respectiva, seu ret angulo de colis ao e identicadores booleanos que
denem seus possveis estados de deadlock, colis ao, atividade, ou r e. Sendo controlada
em conjunto atrav es da classe TrafcController.
Seu construtor possui a funcionalidade de escolher randomicamente entre os possveis
sprites, imagens que ir ao represent a-lo na simulac ao, al em disso, ele guarda um objeto
do tipo Rectangle, derivado da biblioteca Java awt.
Este ret angulo dene a regi ao de colis ao do carro, que n ao segue o tamanho origi-
nal da imagem. Isso se d a da seguinte forma:
1 if(tipo == "ed"){
2 path = "src/imagens/carro" + generator.nextInt(6) + "L.png";
3 x = - 150;
Figure 4. Diagrama UML do pacote Objects
4 y = 85;
5 } else if(tipo == "de"){
6 path = "src/imagens/carro" + generator.nextInt(6) + "R.png";
7 x = 1200;
8 y = 160;
9 }
10 setSprite(new ImageIcon(path));
11 Bounds.setBounds(x, y, Sprite.getIconWidth(), Sprite.
getIconHeight() - 50); //-50: Para nao haver colisao de
altura
12 }
Sua movimentac ao sobre o cen ario 2D depende de sua posic ao na tela, uma vez que,
durante a animac ao, ele precisa se deslocar tamb em verticalmente, no incio e nal da
ponte. Com as devidas correc oes de coordenadas, de acordo com a velocidade escolhida
para a simulac ao. A implementac ao da sua func ao movement se d a, resumidamente, da
seguinte forma:
Verica se est a ativo
N ao movimenta se estiver no estado stop ou deadlock
Caso contr ario, se estiver no estado reverse, inverte o sentido da velocidade,
para dar r e.
Verica se est a nas regi oes crticas, antes ou depois dos sem aforos, ativando o
deslocamento vertical, direto ou reverso, caso seja necess ario.
Movimenta o ret angulo junto com o carro, se estiver no modo reverso, o ret angulo
e deslocado de forma diferente.
A detecc ao de colis ao depende de um algoritmo j a implementado na classe Rectangle
do Java, chamada intersects. Na func ao DetectCollisionFront especicamente, onde e
necess aria uma margem adicional, ela e utilizada da seguinte forma:
1 public boolean DetectCollisionFront(Car car2, int margem){
2 Rectangle c2 = new Rectangle();
3 c2.setBounds(car2.x + margem , car2.y, car2.Sprite.
getIconWidth(), car2.Sprite.getIconHeight());
4 if(colisao && this.Bounds.intersects(c2))
5 return true;
6 return false;
7 }
4.3.2. Semaphore
Finalmente, a classe Semaphore n ao possui nenhuma funcionalidade aut onoma, sendo
controlada completamente atrav es da classe SemaphoreController. Sua principal fun-
cionalidade e guardar seus estados individuais e alterar sua imagem representativa de
acordo com seu estado. Podendo escolher entre quatro imagens( estados ) que s ao:
Sem aforo apagado
Sem aforo verde
Sem aforo amarelo
Sem aforo vermelho
5. Testes e Resultados
Para a obtenc ao dos dados referente as simulac oes dos diferentes tipos de sem aforos
e tratamentos, foi utilizada uma taxa de atualizac ao do thread de 5 e a velocidade da
animac ao utilizada foi igual ` a 4. O processador da m aquina utilizada para a realizac ao
das simulac oes foi Intel Core i5 com um clock de 3.2 GHz.
Para cada tipo de sem aforo ou tratamento de deadlock realizado, o n umero de processos
m edios por segundo foi obtido depois de 20 segundos que a simulac ao estava sendo real-
izada e, para cada caso realizou-se cinco simulac oes.
Inicialmente, foi utilizado um uxo de carros para as simulac oes de 5 para carros no
sentido esquerda-direita e 5 no sentido direita-esquerda. Os dados referentes a cada
simulac ao est ao presentes nas tabelas 1, 2 e 3:
Simulac ao Processos por segundo (Esquerda) Processos por segundo (Direita)
1 0.650 0.600
2 0.700 0.650
3 0.600 0.650
4 0.650 0.600
5 0.700 0.650
Table 1. N umero de processos por segundo utilizando tratamento simples de
deadlock
Simulac ao Processos por segundo (Esquerda) Processos por segundo (Direita)
1 0.900 0.900
2 0.900 0.950
3 1.000 0.950
4 0.850 0.950
5 0.900 1.000
Table 2. N umero de processos por segundo utilizando sem aforo convencional
Simulac ao Processos por segundo (Esquerda) Processos por segundo (Direita)
1 0.947 0.947
2 0.900 1.000
3 0.905 0.952
4 1.000 0.900
5 1.053 0.895
Table 3. N umero de processos por segundo utilizando sem aforo por prioridades
A tabela 4 apresenta as m edias de processos por segundo referente a cada lado, bem como
a m edia total de processos.
Tratamento utilizado M edia processos
Esquerda
M edia processos
Direita
M edia total
de processos
Concludos
Tratamento Deadlock 0,64 0,65 1,29
Sem aforo Convencional 0,91 0,95 1,86
Sem aforo Prioridades 0,961 0,938 1,899
Table 4. M edias do total de processos concludos
Como pode-se perceber ao analisar a tabela 4, os resultados obtidos atrav es das
simulac oes condizem com as expectativas. A primeira forma de tratamento, a qual ocorre
o atraso do processo (a r e do carro, analogamente) e a que apresenta menor m edia de
processos concludos por segundo. J a a segunda e terceira forma de tratamento, sem aforo
convencional e de prioridades respectivamente, apresentam um consider avel aumento no
n umero de processos concludos, devido a implementac ao do sem aforo, o que por sua
vez, melhor o uxo do trafego de carros (processos). H a de se notar que entre a segunda
e a terceira forma de tratamento, n ao h a grande diferenca entre o n umero de processos
concludos, o que e condizente com as expectativas, j a como o n umero de carros e igual
em ambos os lados, a prioridade utilizada pelo sem aforo de prioridades e igual para am-
bos os lados, o que resulta que este funciona praticamente de forma an aloga ao sem aforo
convencional neste caso em especco.
Na segunda etapa do experimento, foi utilizado um uxo de carros para as simulac oes
de 5 para carros no sentido esquerda-direita e 9 no sentido direita-esquerda. Os dados
referentes a cada simulac ao est ao presentes nas tabelas 5, 6 e 7:
Simulac ao Processos por segundo (Esquerda) Processos por segundo (Direita)
1 0,750 0,600
2 0,842 0,789
3 0,842 0,737
4 0,842 0,789
5 0,789 0,737
Table 5. N umero de processos por segundo utilizando tratamento simples de
deadlock
Simulac ao Processos por segundo (Esquerda) Processos por segundo (Direita)
1 0,947 1,263
2 0,947 1,105
3 1,053 1,158
4 0,850 1,150
5 1,105 1,211
Table 6. N umero de processos por segundo utilizando sem aforo convencional
Simulac ao Processos por segundo (Esquerda) Processos por segundo (Direita)
1 0,895 1,474
2 0,947 1,368
3 0,800 1,450
4 0,895 1,368
5 1,000 1,368
Table 7. N umero de processos por segundo utilizando sem aforo por prioridades
A tabela 8 apresenta as m edias de processos por segundo referente a cada lado, bem como
a m edia total de processos.
Tratamento utilizado M edia processos
Esquerda
M edia processos
Direita
M edia total
de processos
Concludos
Tratamento Deadlock 0,813 0,73 1,543
Sem aforo Convencional 0,98 1,177 2,157
Sem aforo Prioridades 0,907 1,405 2,312
Table 8. M edias do total de processos concludos
Novamente, os resultados das simulac oes condizem com o esperado. Nota-se que quando
e utilizado o simples tratamento de deadlock o n umero de processos concludos e no-
vamente, signicativamente menor e os outros casos. J a no caso em que se compara o
n umero de processos dos sem aforos convencional e por prioridade, nota-se que o por pri-
oridades tem uma eci encia melhor do que o convencional, pois devido a administrac ao
que este efetua, liberando mais recursos (neste caso, tempo) para o lado em que h a maior
tr afego, este consegue completar mais processos que o sem aforo convencional, o qual
funciona do mesmo jeito independente do trafego.
6. Conclusoes
Atrav es das simulac oes realizadas, foi possvel comparar diferentes tratamentos de dead-
lock para o problema da ponte. Utilizando-se da comparac ao dos n umeros de processos
realizados por minuto em cada caso, foi possvel a avaliac ao da eci encia relativa entre
os tr es tipos de tratamentos utilizados: tratamento simples de deadlock, tratamento uti-
lizando sem aforo convencional e utilizando sem aforo por prioridades. Atrav es da an alise
dos resultados, foi possvel vericar que o tratamento que em m edia e mais eciente e o
do sem aforo por prioridades, seguido do convencional e por ultimo o tratamento simples
de deadlock.
References
Silberschatz, A., Galvin, P., and Gagne, G. (2010). Fundamentos de sistemas opera-
cionais. LTC.