Algoritmo do banqueiro

Algoritmo do banqueiro
O Algoritmo do banqueiro um algoritmo de alocao de recursos com preveno de impasses desenvolvido por Edsger Dijkstra que testa a segurana pela simulao da alocao do mximo pr-determinado possvel de montantes de todos os recursos computacionais, e em seguida faz uma verificao de estados-seguros para testar a possibilidade de condies de impasse para todas as outras atividades pendentes, antes de decidir se a alocao deve prosseguir. O algoritmo foi desenvolvido no durante o projeto do sistema operacional THE e originalmente descrito (em Holands) em EWD108.[1] O nome por analogia a maneira com que os banqueiros respondem por constrangimentos de liquidez.

Algoritmo
O algoritmo do banqueiro executado pelo sistema operacional quando um processo de computao requisita recursos..[2] O algoritmo impede o impasse, ao negar ou adiar o pedido se ele determinar que aceitar o pedido pode colocar o sistema em um estado inseguro (onde um impasse poderia ocorrer). Quando um novo processo entra em um sistema, ele deve declarar o nmero mximo de instncias de cada tipo de recurso que no pode exceder o nmero total de recursos no sistema.

Recursos
Para o algoritmo do banqueiro trabalhar, ele precisa saber trs coisas: Quanto de cada recurso cada processo poderia solicitar Quanto de cada recurso cada processo atualmente detm Quanto de cada recurso o sistema tem disponvel Recursos podem ser atribudos a um processo somente se forem preenchidas as seguintes condies: 1.Pedido <= mximo, seno ajuste a condio de erro definida como o processo ultrapassou a quantidade mxima feita por ele. 2.Pedido <= disponvel, seno o processo tem que esperar at que mais recursos estejam disponveis. Alguns dos recursos que so controlados em sistemas reais so memria, semforos e interfaces de acesso. Exemplo Supondo que o sistema distingue quatro tipos de recursos, (A, B, C e D), o seguinte um exemplo de como esses recursos poderiam ser distribudos. Note que este exemplo mostra o sistema em um instante antes de um novo pedido de recursos chegar. Alm disso, os tipos e nmero de recursos so abstrados. Sistemas reais, por exemplo, lidariam com quantidades muito maiores de cada recurso. Recursos do sistema disponveis so: A B C D 3 1 1 2 Processos (recursos atualmente alocados): A B C D P1 1 2 2 1 P2 1 0 3 3 P3 1 1 1 0 Processos (mximo de recursos): A B C D

Algoritmo do banqueiro P1 3 3 2 2 P2 1 2 3 4 P3 1 1 5 0

Estados seguros e inseguros

Um estado (como no exemplo acima) considerada seguro se possvel para todos os processos concluir sua execuo (terminar). Desde que o sistema no pode saber quando o processo ser encerrado, ou quantos recursos ele ter solicitado at ento, o sistema assume que todos os processos acabaro por tentar adquirir o mximo de seus recursos previstos e encerrar logo depois. Esta uma suposio razovel na maioria dos casos uma vez que o sistema no est particularmente preocupado com o tempo que cada processo executado (pelo menos no numa perspectiva de preveno de deadlocks). Alm disso, se um processo termina sem adquirir o seu mximo de recursos, isto s torna mais fcil para o sistema. Dada esta premissa, o algoritmo determina se um estado seguro, tentando encontrar um conjunto hipottico de pedidos pelos processos que permitiriam a cada, a aquisio de seus recursos mximos e depois o seu trmino (retornando os seus recursos para o sistema). Qualquer estado onde tal conjunto no existe definido como um estado inseguro. Pseudocdigo function algoritmo_do_banqueiro(conjunto de processos P, recursos atualmente disponveis A) { while (P no vazio) { boolean achou = false for each (processo p in P) { Cp = atual alocao de recursos para o processo(p) Mp = requisito mximo de recursos para o processo(p) if (Mp Cp A) { // p pode obter tudo de que necessita. // Suponha que ele faz isso, termina, e libera o que ele j tem. A = A + Cp remove_elemento_do_conjunto(p, P) achou = true } } if (not achou) { return INSEGURO } } return SEGURO }
[3]

Algoritmo do banqueiro Exemplo Podemos mostrar que o estado dado no exemplo anterior um estado de segurana, mostrando que possvel para cada processo adquirir o mximo de seus recursos e, em seguida, finalizar. 1. P1 adquire os recursos 2 A, 1 B e 1 D, atingindo o seu mximo O sistema agora ainda tem 1 A, nenhum B, 1 C e 1 D como recursos disponveis 2. P1 termina, retornando os recursos 3 A, 3 B, 2 C e 2 D para o sistema O sistema tem agora os recursos disponveis 4 A, 3 B, 3 C e 3 D 3. P2 adquire 2 B e 1 D recursos extras, ento termina, retornando todos os seus recursos O sistema tem agora os recursos 5 A, 3 B, 6 C e 6 D 4. P3 adquire os recursos 4 C e termina O sistema tem agora todos os recursos: 6 A, 4 B, 7 C e 6 D 5. Porque todos os processos foram capazes de terminar, esse estado seguro Note-se que estes pedidos e aquisies so hipotticos. O algoritmo gera eles para verificar a segurana do estado, mas nenhum recurso efectivamente dado e nenhum processo realmente termina. Observe tambm que a ordem em que esses pedidos so gerados - se vrios possam ser satisfeitos - no importa, porque todos os pedidos hiptticos deixam o processo terminar, aumentando assim os recursos livres do sistema. Para um exemplo de um estado inseguro, considere o que aconteceria se o processo 2 estavesse segurando mais 1 unidade do recurso B no incio.

Pedidos
Quando o sistema recebe um pedido de recursos, executado o algoritmo do banqueiro para determinar se ele seguro com o propsito de se deferir o pedido. O algoritmo bastante simples uma vez a distino entre os Estados seguros e inseguros ter sido compreendida. 1. 2. 3. 4. 5. 6. Pode o pedido ser concedido? * Se no, o pedido impossvel e deve ser negado ou colocado em lista de espera Suponha que o pedido concedido O novo estado seguro? * Sendo assim deferir o pedido * Se no, negar o pedido, ou coloc-lo em uma lista de espera

Se o sistema nega ou adiar um pedido impossvel ou inseguro uma deciso especfica do sistema operacional. Exemplo Continuando o exemplo anterior, suponha que o processo 3 solicite 2 unidades de recursos C. 1. No h o suficiente de recursos de C disponveis para deferir o pedido 2. O pedido negado Por outro lado, assuma-se que o processo 3 pedidos solicite 1 unidade do recurso C. 1. Existem recursos suficientes para deferir o pedido 2. Suponha que o pedido for deferido 3. * O novo estado do sistema seria: Recursos do sistema disponveis so: A B C D Livres 3 1 0 2

Algoritmo do banqueiro Processos (recursos atualmente alocados): A B C D P1 1 2 2 1 P2 1 0 3 3 P3 1 1 2 0 Processos (recursos mximos): A B C D P1 3 3 2 2 P2 1 2 3 4 P3 1 1 5 0 1. Determinar se este novo estado seguro 1. P1 pode adquirir os recursos 2 A, 1 B e 1 D e finalizar 2. Ento, P2 pode adquirir os recursos 2 B e 1 D e finalizar 3. Finalmente, P3 pode adquirir os recursos 3 C e terminar 4. Assim, este novo estado seguro 2. Uma vez que o novo estado seguro, deferir o pedido Finalmente, suponha que o processo 2 requisite 1 unidade de recursos B. 1. Existem recursos suficientes 2. Supondo que o pedido seja deferido, o novo estado seria: Recursos do sistema disponveis so: A B C D Livres 3 0 1 2 Processos (recursos atualmente alocados): A B C D P1 1 2 2 1 P2 1 1 3 3 P3 1 1 1 0 Processos (recursos mximos): A B C D P1 3 3 2 2 P2 1 2 3 4 P3 1 1 5 0 1. Este estado seguro? Assumindo que P1, P2 e P3 requisitem mais dos recursos B e C. P1 incapaz de adquirir recursos suficientes de B P2 incapaz de adquirir recursos suficientes de B P3 incapaz de adquirir recursos suficientes de C Nenhum processo pode adquirir recursos suficientes para finalizar, assim que este estado no seguro 2. Uma vez que o estado inseguro, negar o pedido Note que neste exemplo, nenhum processo foi capaz de terminar. possvel que alguns processos estejam aptos a terminar, mas no todos eles. Isso ainda seria um estado inseguro.

Algoritmo do banqueiro

Trade-offs
Como a maioria dos algoritmos, o algoritmo do banqueiro envolve alguns dilemas (trade-offs). Especificamente, ele precisa saber o quanto de cada recurso de um processo poderia ser requerido. Na maioria dos sistemas, esta informao no est disponvel, fazendo com que o algoritmo do banqueiro seja intil. Alm disso, irrealista supor que o nmero de processos seja esttico. Na maioria dos sistemas o nmero de processos varia dinamicamente. Alm disso, a exigncia de que um processo acabar por liberar todos os seus recursos (quando o processo termina) suficiente para a correo do algoritmo, porm no suficiente para um sistema prtico. Esperar por horas (ou at mesmo dias) que os recursos sejam liberados normalmente no aceitvel.

Leitura complementar
"Operating System Concepts [4]" by Silberschatz, Galvin, and Gagne (pages 259-261 of the 7th edition) "EWD623: The mathematics behind the Bankers Algorithm [5]" (1977) by E. W. Dijkstra, published as pages 308312 of Edsger W. Dijkstra, Selected Writings on Computing: A Personal Perspective, Springer-Verlag, 1982. ISBN 0-387-90652-5

Ligaes externas
Deadlock Recovery, Avoidance and Prevention [6]
[1] E. W. Dijkstra " EWD108: Een ter algorithme voorkoming van de omarming dodelijke (http:/ / www. cs. utexas. edu/ users/ EWD/ ewd01xx/ EWD108. PDF)" (em holands; Um algoritmo para a preveno do abrao mortal) [2] Bic, Lubomir F.; Shaw, Alan C.. Operating System Principles. 2ed. [S.l.]:Prentice Hall, 2003. ISBN 0-13-026611-6 [3] Concurrency (http:/ / www. cs. huji. ac. il/ course/ 2006/ os/ notes/ notes4. pdf) [4] http:/ / codex. cs. yale. edu/ avi/ os-book/ os7 [5] http:/ / www. cs. utexas. edu/ users/ EWD/ ewd06xx/ EWD623. PDF [6] http:/ / www. isi. edu/ ~faber/ cs402/ notes/ lecture9. html

Fontes e Editores da Pgina

Fontes e Editores da Pgina

Algoritmo do banqueiro Fonte: http://pt.wikipedia.org/w/index.php?oldid=33975813 Contribuidores: Faustino.F, Marcos Elias de Oliveira Jnior, Ricardo Ferreira de Oliveira, 5 edies annimas

Licena
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/