Nota: Estimados alumnos, deben ustedes ejcutar el cdigo de cualquiera de los algoritmos expuestos en el archivo y exponer la prxima semana

en el horario de laboratorio, deben ejrcitarse en ejecutar el programa para que ilustre la forma como se atienden los procesos en el sistema. En que tipos de procesamiento se implementan estos algoritmos tambin es bueno que los indiquen en su exposicin.

Banquero
Llamado tambin negativa de asignacin de recursos, el algoritmo resuelve un problema planteado por Edsger Dijkstra. Existe un banco que tiene una reserva limitada de dinero a prestar y clientes con lnea de crdito. Un cliente pide dinero y no hay garanta de que haga reposiciones hasta que saque la cantidad mxima. El banco puede rechazar el prstamo si hay riesgo de que no tenga fondos para prestar a otros clientes Vindolo como Sistema Operativo, los clientes seran los procesos, el dinero a prestar los recursos y el banquero el S.O. Para este algoritmo es importante considerar los siguientes puntos:
y y y y y

Estado. Es la asignacin actual de los recursos a los procesos. Matriz demanda (o mximo necesario). Son las exigencias mximas de recursos para cada proceso. Matriz asignacin. Son las asignaciones actuales de recursos para cada proceso. Vector disponible. Cantidad total de recursos sin asignar a los procesos. Estado seguro. Es un estado en el que existe al menos un orden en el que todos los procesos pueden ejecutar hasta el final sin generar interbloqueo.

Cuando un proceso realiza una solicitud de recursos, se supone que se concede, se actualiza el estado y se toma una decisin. Si se llega a un estado seguro, se concede la peticin. Si se llega a uno inseguro, se rechaza y el proceso es bloqueado. A continuacin se presenta un ejemplo: Utilizando el algoritmo del banquero resuelva el siguiente problema, indicando el orden en que los procesos pasan a ser estados seguros evitando el problema del interbloqueo.

2011

Sistemas Operativos

Lista de procesos: P1-P3-P4-P0 P2 A la derecha se tienen 5 procesos, cada uno tiene recursos de tipo A, B y C. En la primera columna de asignados est la cantidad de recursos que el proceso ha obtenido a lo largo de un tiempo; en la segunda columna de Mximo Necesario, estn los recursos que tiene que obtener de cada tipo para comenzar a ser ejecutado. Por ejemplo, el P0 no ha obtenido ningn recurso del tipo A, slo 1 del tipo B y ninguno del tipo C, y necesita para ejecutarse haber conseguido 7 del A, 5 del B y 3 del C. En la ltima columna se tienen los recursos disponibles que da el sistema, los que se pueden utilizar con todos los procesos. Hay 3 del A, 3 del B y 2 del C. El algoritmo del banquero trata de asegurar qu proceso tiene un estado seguro es decir, se requiere alcanzar el mximo requerido entre los que estn en Asignados y los que se encuentren en Disponibles. Ejemplo: El proceso 0 no est en estado seguro. Si se suman Asignados + Disponibles para cada uno de los recursos A, B y C, realmente no se alcanzan los Mximos Requeridos. Entonces se va al proceso 1 y se trata de hacer lo mismo, sumar Asignados + Disponibles. All s se tiene un ESTADO SEGURO, A con 5, B con 3 y C con 2, y como se alcanza a llenar los Mximos, ese proceso se ejecuta. Una vez que el proceso se ejecut, entonces se procede a SUMAR los recursos asignados del proceso anterior a los disponibles. Hay que recordar que el proceso al terminar de ejecutarse libera todos sus recursos, por lo tanto pasan tanto los de tipo A, B y C a sumarse con los disponibles 3-3-2 y se tendrn nuevos DISPONIBLES que repartir, siendo ahora stos 5-3-2. Con estos se pasa al proceso P2 y as sucesivamente. Y el algoritmo es como sigue:

Pgina | 2

Sistemas Operativos

Ventajas del algoritmo del banquero:

y

No es necesario expulsar y hacer retroceder procesos como en la deteccin del interbloqueo. Pgina | 3

Sistemas Operativos
y

Es menos restrictivo que la prevencin.

Desventajas:
y y y y y

Se debe conocer la mxima demanda de recursos por anticipado. La ejecucin de los recursos no debe estar forzada por la sincronizacin. Se tiene un nmero fijo de procesos y recursos. Los procesos no finalizan mientras retengan recursos. Requiere que los procesos salden sus prstamos en un tiempo finito.

Pgina | 4

Sistemas Operativos Proceso de Ejecucin

package banquero; import javax.swing.JOptionPane; public class Main { public static void main(String[] args) { //cliente uno int cuenta1 = 2500; //cliente dos int cuenta2 = 3500; //cliente tres int cuenta3 = 1500; String retiro1 = JOptionPane.showInputDialog("ingrese retiro1: " + " cuenta: "+cuenta1); String retiro2 = JOptionPane.showInputDialog("ingrese retiro2: " + " cuenta: "+cuenta2); String retiro3 = JOptionPane.showInputDialog("ingrese retiro3: " + " cuenta: "+cuenta3); int r1 = Integer.parseInt(retiro1); int r2 = Integer.parseInt(retiro2); int r3 = Integer.parseInt(retiro3); if ((r1==cuenta1 || r1<cuenta1) && (r2==cuenta2 || r2<cuenta2) && (r3==cuenta3 || r3<cuenta3)){ System.out.println("proceso uno en ejecucion y estado seguro...!!!"); System.out.println("proceso dos en ejecucion y estado seguro...!!!"); System.out.println("proceso tres en ejecucion y estado seguro...!!!"); } else if((r1==cuenta1 || r1<cuenta1) && (r2!=cuenta2 || r2>cuenta2) && (r3==cuenta3 || r3<cuenta3)){ System.out.println("proceso uno en ejecucion y estado seguro...!!!"); System.out.println("proceso dos bloqueado por causar estado inseguro...!!!"); System.out.println("proceso tres en ejecucion y estado seguro...!!!"); } else if((r1 == cuenta1 || r1 < cuenta1) && (r2 == cuenta2 || r2 < cuenta2) && (r3 != cuenta3 || r3 > cuenta3)) { System.out.println("proceso uno en ejecucion y estado seguro...!!!"); System.out.println("proceso dos en ejecucion y estado seguro...!!!"); System.out.println("proceso tres bloqueado por causar estado inseguro...!!!");

Pgina | 5

Sistemas Operativos
} else if((r1 != cuenta1 || r1 > cuenta1) && (r2 == cuenta2 || r2 < cuenta2) && (r3 == cuenta3 || r3 < cuenta3)) { System.out.println("proceso tres bloqueado por causar estado inseguro..."); System.out.println("proceso dos en ejecucion y estado seguro...!!!"); System.out.println("proceso uno en ejecucion y estado seguro...!!!!!!"); } } }

Pgina | 6

Sistemas Operativos

Pgina | 7

Sistemas Operativos

Pgina | 8

Sistemas Operativos

Semforo
Es una herramienta de sincronizacin y y Sirve para solucionar el problema de la seccin crtica. Sirve para solucionar problemas de sincronizacin.

Implementacin y y y y y y y y Es una variable entera sujeta a dos operaciones: wait y signal Estas operaciones se ejecutan de manera indivisible. Cuando un proceso modifica el valor del semforo, otros procesos no pueden modificarlo simultneamente. Se inicializa con valor no negativo Wait decrementa el valor del semforo. Si el valor se hace negativo, el proceso se bloquea. Signal incrementa el valor del semforo. Si el valor no es positivo, se desbloquea un proceso bloqueado por un wait.

Esquema de la SC con semforos y y y y y y Repeat Entry section critical section Exit section Remainder section Until false;

Ejemplo Sean 2 procesos: y y y A, que quiere ejecutar la sentencia X B, que quiere ejecutar la sentencia Y. Sem, es la variable comn semforo, inicializada en 0.

Pero: Y se debe ejecutar despus que X Solucin:  En proceso A: X; Signal(sem); Sistemas Operativos UTN . FRM  En proceso B: Pgina | 9

Sistemas Operativos

Wait(sem); Y; Alternativas en la espera y y y y Busy waiting: gasta CPU, ejecuta un loop hasta poder entrar a SC. Autobloqueo: cuando el proceso ve que tiene que esperar, se bloquea. Se pone en una cola asociada con el semforo. Se rearranca por un wakeup cuando se ejecuta el signal en los procesos en SC.

Problemas al NO usar semforos Lo primero es ver una aplicacin fictica corriendo SIN el uso de los semforos, para luego entender mejor su utilidad. Su pongamos que tenemos 4 procesos (p1, p2, p3, p4), cada proceso realiza su tarea simultaneamente (durante un tiempo indefinido) y posteriormente termina. Supongamos adems que necesitamos que se ejecuten primero los procesos P1 y P3, y luego P2 y P4. Tenemos entonces: P1.java
public class p1 extends Thread { public void run() { try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P1"); } }

P2.java
public class p2 extends Thread { public void run() { try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P2"); } }

P3.java
public class p3 extends Thread { public void run() {

Pgina | 10

Sistemas Operativos
try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P3"); } }

P4.java
public class p4 extends Thread { public void run() { try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P4"); } }

y la clase SinSemaforos.java, que lanza los subprocesos:

public class SinSemaforos { public static void main(String[] args) { (new Thread(new p1())).start(); (new Thread(new p2())).start(); (new Thread(new p3())).start(); (new Thread(new p4())).start(); } }

Ejecutando varias veces este programa, tendremos salidas como: # java SinSemaforos P4 P2 P1 P3 # java SinSemaforos P2 P1 P3 P4 # java SinSemaforos P2 P1 P4 P3 Pgina | 11

Sistemas Operativos Como puedes ver, los procesos se ejecutan sin cumplir la condicin ms importante: que se ejecuten primero los procesos P1 y P3, y posteriormente P2 y P4. Solucionemos esto con el uso de semforos!

Solucin usando semforos

En este caso vamos a usar la clase Semaphore, del paquete java.util.concurrent. A darle entonces: Tenemos entonces P1.java:
import java.util.concurrent.Semaphore; public class p1 extends Thread { protected Semaphore oFinP1; public p1(Semaphore oFinP1) { this.oFinP1 = oFinP1; } public void run() { try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P1"); this.oFinP1.release(2); } }

P2.java
import java.util.concurrent.Semaphore; public class p2 extends Thread { protected Semaphore oFinP1; protected Semaphore oFinP3; public p2(Semaphore oFinP1,Semaphore oFinP3) { this.oFinP3 = oFinP3; this.oFinP1 = oFinP1; } public void run() { try { this.oFinP1.acquire(); this.oFinP3.acquire(); } catch(Exception e) { e.printStackTrace(); } try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P2"); } }

Pgina | 12

Sistemas Operativos P3.java

import java.util.concurrent.Semaphore; public class p3 extends Thread { protected Semaphore oFinP3; public p3(Semaphore oFinP3) { this.oFinP3 = oFinP3; } public void run() { try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P3"); this.oFinP3.release(2); } }

P4.java
import java.util.concurrent.Semaphore; public class p4 extends Thread { protected Semaphore oFinP1; protected Semaphore oFinP3; public p4(Semaphore oFinP1,Semaphore oFinP3) { this.oFinP3 = oFinP3; this.oFinP1 = oFinP1; } public void run() { try { this.oFinP1.acquire(); this.oFinP3.acquire(); } catch(Exception e) { e.printStackTrace(); } try { sleep((int) Math.round(500 * Math.random() - 0.5)); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("P4"); } }

y la clase UsoSemaforos.java, que lanza los subprocesos:

import java.util.concurrent.Semaphore; public class UsoSemaforos { protected static Semaphore oFinP1,oFinP3; public static void main(String[] args) { oFinP1 = new Semaphore(0,true); oFinP3 = new Semaphore(0,true); (new Thread(new p1(oFinP1))).start(); (new Thread(new p2(oFinP1,oFinP3))).start();

Pgina | 13

Sistemas Operativos
(new Thread(new p3(oFinP3))).start(); (new Thread(new p4(oFinP1,oFinP3))).start(); } }

Ejecutando varias veces el programa, podemos ver como los subprocesos P1 y P3 se ejecutan siempre de primeras, y los procesos P2 y P4, de ltimas: #java UsoSemaforos P3 P1 P2 P4 #java UsoSemaforos P1 P3 P2 P4 #java UsoSemaforos P3 P1 P4 P2 #java UsoSemaforos P1 P3 P4 P2 Conclusiones
y y

Lo primero es el mtodo acquire() de la clase Semaphore. Este mtodo bloquea el semforo premanetemente (wait); mientras que, el mtodo release() de la clase Semaphore, libera el semforo para los dems procesos (signal).

Pgina | 14

Sistemas Operativos

Cena de los Filsofos

Haba una vez cinco filsofos que vivan juntos. La vida de cada filsofo consista principalmente en pensar y comer y, tras aos de pensar, todos los filsofos se haban puesto de acuerdo en que la nica comida que contribua a sus esfuerzos eran los espaguetis.

Los preparativos de la comida eran simples : una mesa redonda en la que haba una gran fuente de espaguetis, cinco platos, uno para cada filsofo y cinco tenedores. Un filsofo que quisiera comer ira a su lugar asignado en la mesa y, usando los dos tenedores de cada lado del plato, cogera los espaguetis y se los comera. El problema es lo siguiente : inventar un ritual (algoritmo) que permita comer a los filsofos. El algoritmo debe satisfacer la exclusin mutua (dos filsofos no pueden emplear el mismo tenedor a la vez), adems de evitar el interbloqueo y la inanicin (en este caso, este ultimo termino tiene un significado literal adems del algortmico). Este problema, propuesto por Dijkstra, puede no parecer importante o relevante por si mismo. Sin embargo, sirve para ilustrar los problemas bsicos del interbloqueo y la inanicin. Es ms, intentar desarrollar una solucin revela muchas de las dificultades de la programacin concurrente. Adems, el problema de la cena de los filsofos puede verse como un caso representativo de los problemas relacionados con la coordinacin sobre recursos compartidos, que se produce cuando una aplicacin incluye hilos de ejecucin concurrentes. Por consiguiente, este problema es un caso de prueba estndar para examinar soluciones a la sincronizacin. Una primera solucin al problema de la cena de los filsofos es:
/* program cena_filsofos */ semforo tenedor[5] = {1}; int i; void filosofo(int i) { while (cierto) {

Pgina | 15

Sistemas Operativos
pensar ( ); wait (tenedor [i]); wait (tenedor [(i + 1)mod 5]; comer ( ); signal (tenedor [(i + 1) mod 5]); wait (tenedor [1]); } } void main ( ) { parbegin (filosofo filosofo (4)); }

(0),

filosofo (1), filosofo

(2),

filosofo (3),

Sugiere una solucin por medio de semforos. Cada filosofo toma 1 el tenedor de su izquierda , y despus el de su derecha. Cuando un filosofo termina de comer, devuelve los dos tenedores a la mesa. Esta solucin, desafortunadamente, produce nterbloqueo: si todos los filsofos estn hambriento al mismo tiempo, todos se sientan, todos toman el tenedor de su izquierda y todos intentan tomar el otro tenedor que no estar. Esta solucin es poco decorosa, pues todos los filsofos pasan hambre.Para superar el riesgo de nter bloqueo se podran adquirir 5 tenedores adicionales ( una solucin mas saludable), o ensear a los filsofos a comer espaguetis con un solo tenedor.

Como otra solucin posible , se podra considerar incorporar un sirviente que permita pasar solo a 4 cuatro filsofos a la vez al comedor. Con un mximo de 4 filsofos sentados, al menos uno de los filsofos tendr acceso a los dos tenedores. En esta figura se muestra con semforos. Esta solucin esta libre de nter bloqueo e inanicin.
/* program cena_filsofos */ semforo tenedor[5] = {1}; semforo habitacin = {4}; int i; void filosofo (int i) { while (cierto) pensar ( ); wait (habitacin); wait (tenedor [i]); wait (tenedor [(i + 1) mod 5]); comer ( ); signal (tenedor [(i +1) mod 5]); wait (tenedor [i]); signal (habitacin); } void main ( ) { parbegin (filosofo (0), filosofo (1), filosofo filosofo (4)); }

(2),

filosofo (3),

Pgina | 16

Sistemas Operativos

Pgina | 17

Sistemas Operativos

Bibliografa
 http://sistemas-operativos.blogspot.com/2006/05/algoritmo-del-banquero.html  http://casidiablo.net/semaforos-java/  http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/CINTIN02 .htm  Sistemas Operativos Modernos. Andrew S. Tanenbaum

Pgina | 18