Deberoperativos

Fecha de elaboracin: ____Enero 2012____
UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERA EN CIENCIAS FSICAS Y MATEMTICAS ESCUELA DE CIENCIAS
CARRERA Ingeniera en Informtica y Ciencias de la Computacin TRABAJO 1 TEMA TTULO Consulta
NOMBRE DE LA ASIGNATURA SISTEMAS OPERATIVOS II DURACI N15 das (HORA)
Monitores, paso de mensajes y problema de los filsofos
1. Facilidades de uso de los monitores y paso de mensajes en 1. Facilidades de uso de los monitores y paso de mensajes en sistemas
operativos estandares
1.1
Monitores
Para entender este tema empezamos conociendo que son monitores. Un monitor es un constructor de lenguaje de programacin que soporta tanto la sincronizacin de acceso de datos como la de controles. Un tipo de monitor se parece a una clase en un lenguaje como C++ o Java. Son mdulos que encierran los recursos o variables compartidas como componentes internos privados y ofrece una interfaz de acceso a ellos que garantiza el rgimen de exclusin mutua. La declaracin de un monitor incluye:
Declaracin de las constantes, variables, procedimientos y funciones que son privados del monitor (solo el monitor tiene visibilidad sobre ellos). Declaracin de los procedimientos y funciones que el monitor exporta y que constituyen la interfaz a travs de las que los procesos acceden al monitor. Cuerpo del monitor, constituido por un bloque de cdigo que se ejecuta al ser instanciado o inicializado el monitor. Su finalidad es inicializar las variables y estructuras internas del monitor.
El monitor garantiza el acceso al cdigo interno en rgimen de exclusin mutua. El monitor tiene asociada una lista en la que se incluyen los procesos que al tratar de acceder al monitor son suspendidos. 1.1 Sintaxis de un monitor
Sistemas Operativos II
Pgina 1

monitor Identificador; -- Lista de procedimientos y funciones exportadas export Identificador_procedimiento_1; export Identificador_procedimiento_2; .... -- Declaracin de constantes, tipos y variables internas .... -- Declaracin de procedimientos y funciones .... begin -- Sentencias de inicializacin .... end;
1.2
Aspectos caractersticos de un monitor Las estructuras de datos internas del monitor cuya finalidad es ser compartidas por mltiples procesos concurrentes, solo pueden ser inicializadas, ledas y actualizadas por cdigo propio del monitor. Los nicos componentes del monitor pblicos (visibles desde mdulos externos) son los procedimientos y funciones exportadas. El monitor garantiza el acceso mutuamente exclusivo a los procedimientos y funciones de la interfaz. Si son invocados concurrentemente por varios procesos, solo la ejecucin de un procedimientos del monitor es permitido. Los procesos no atendidos son suspendidos hasta que la ejecucin del procedimiento atendido acabe. Dado que todo el cdigo relativos a un recurso o a una variable compartida est incluido en el mdulo del monitor, su mantenimiento es mas fcil y su implementacin es ms eficiente.
Los monitores localizan en su cdigo todos los componentes del programa relativos a una variable compartida. El mantenimiento de los programas basados en monitores es mucho ms simple que en los basados en regiones crticas. El monitor resuelve el acceso seguro a recursos y variables compartidos, pero no tiene las capacidades plenas de sincronizacin. Las variables tipos condition que solo pueden declararse dentro de un monitor proporciona a los monitores la capacidad de sincronizacin plena.
Sistemas Operativos II Pgina 2

Condition es un tipo de variable predefinido que solo puede intanciarse en los monitores: var inviables: condition
Valores: No toma ningn tipo de valor, pero tiene asociada una lista de procesos suspendidos Operaciones: Delay suspende el proceso que lo ejecuta y lo incluye en la lista de una variable Condition. Resume Reactiva un proceso de la lista asociada a una variable Condition. Empty Funcin que retorna True si la lista de procesos de la variable est vaca. Aspectos de un tipo de monitor
1.1
Declaracin de datos: aqu se declaran datos compartidos y variables de condicin. Copias de estos datos existen cada objeto de un tipo de monitor. Inicializacin de datos: se inicializan datos cuando un monitor, es decir, un objeto de un tipo de monitor, es creado. Operaciones con datos: las operaciones con datos compartidos son codificadas como compartidos procedimientos del tipo monitor. El monitor asegura que estas operaciones sean ejecutadas en forma mutuamente exclusiva. Operacin de sincronizacin: los procedimientos del tipo monitor prefieren el uso de operaciones de sincronizacin wait y signal sobre variables de condicin para sincronizar la ejecucin de procesos. El acceso al monitor est permitido solamente a travs de los procedimientos pblicos y el compilador garantiza exclusin mutua para todos los procedimientos. La implementacin del monitor controla la exclusin mutua con colas de entrada que contengan todos los procesos bloqueados. Pueden existir varias colas y el controlador del monitor elige de cual cola se va a escoger el siguiente proceso para actuar sobre los datos. Un monitor no tiene acceso a
Pgina 3

variables exteriores con el resultado de que su comportamiento no puede depender de ellos. Una desventaja de los monitores es la exclusividad de su uso, es decir, la concurrencia est limitada si muchos procesos hacen uso del mismo monitor. 1.2 Facilidades del uso de monitores:
Una de las facilidades que se encuentra en el uso de monitores es la sincronizacin condicional, es decir, mientras un procesos est ejecutando un procedimiento del monitor (con exclusin mutua) puede dar paso a otro proceso liberando el cerrojo. La tcnica permite la sincronizacin entre procesos porque actuando sobre el mismo recurso los procesos pueden cambiar el estado del recurso y pasar as informacin de un proceso a otro. Lenguajes de alto nivel que facilitan la programacin concurrente suelen tener monitores implementados dentro del lenguaje (por ejemplo refJavaMonitoresJava usa el concepto de monitores para realizar el acceso mutuamente exclusivo a sus objetivos). El uso de monitores es bastante costo, porque se pierde eficiencia por tanto bloqueo de los procesos. Por eso se intenta aprovechar de primitivas ms potentes para aliviar este problema. Un monitor garantiza el acceso al cdigo interno en un rgimen de exclusin mutua. Esto implica que el monitor tiene asociada una lista en la que se incluyen todos los procesos que tratan de acceder a procedimientos del monitor y que por el rgimen de exclusividad, tiene que esperar a que este quede libre. La implementacin de los semforos es una parte bsica de sincronizacin para programas concurrentes. Comprobar que los monitores son capaces de implementar semforos representa comprobar que los monitores resuelven todos los problemas requeridos en programacin concurrente. La sincronizacin a travs de semforos presenta la capacidad plena, pero su facilidad de uso es muy pobre por su bajo nivel de abstraccin y su gestin distribuida.
Pgina 4

Los monitores incrementan la abstraccin y concentran su gestin, pero al finar requieren variables Condition que son tambin de muy bajo nivel de abstraccin aunque permanecen localizadas en el monitor. Las estructuras tipo Monitor constituyen un mtodo efectivo de encapsular recursos compartidos, constituye la mejor abstraccin de un recurso si excluimos su modelado mediante un proceso. No obstante, presenta el problema de requerir variables condicionadas para que cubra la totalidad de las posibilidades de sincronizacin. 1.3 Paso de mensajes en sistemas operativos estndares
El paso de mensajes es una tcnica empleada en programacin concurrente para aportar sincronizacin entre procesos y permitir la exclusin mutua, de manera similar a como se hace con los semforos, monitores, etc. Su principal caracterstica es que no precisa de memoria compartida, por lo que es muy importante en la programacin para sistemas distribuidos. 1.3.1 Paradigma de paso de mensajes
HW de paso de mensajes API de paso de mensajes Sist. de paso de mensajes: Capa sobre protocolo de transporte Si nivel de transporte subyacente (p.e. UDP) no garantiza: Recepcin correcta, orden, control de flujo, fragmentacin. Debe hacerlo propio s. paso de mensajes si pretende esa garanta timeouts, ACKs, deteccin de duplicados, control de flujo, fragmentacin/compactacin de mensajes, etc.
Ejemplos de alternativas con distintos niveles de funcionalidad Bsicamente funcionalidad de nivel de transporte: sockets Paso de mensajes orientado a la programacin paralela: MPI Extensin del paso de mensajes de un microkernel a SD: Mach Message-oriented middleware (MOM): Sistema de colas de mensajes
IBM WebSphere Message Broker, MSMQ, Java Message Service
Pgina 5

1.1.1 Sistemas de colas de mensajes Envo/recepcin mensajes a colas con comunicacin persistente: Comunicacin convencional Destinatario debe estar presente cuando se recibe mensaje Comunicacin persistente No es necesario que proceso receptor est presente Sistema de comunicacin guarda mensaje Comunicacin dbilmente acoplada Emisor (E) y receptor (R) totalmente desacoplados: En nombrado: E y R no se conocen; slo comparten nombre de cola En el tiempo: no necesitan coincidir Modelos punto-a-punto (N N) y editor/subscriptor (N N) Message Broker: componente que transforma formato mens. Apropiada para integracin de aplicaciones de empresa (EAI) Operaciones avanzadas: transacciones, encaminamiento por contenido Los elementos principales que intervienen en el paso de mensajes son el proceso que enva, el que recibe y el mensaje. Sus caractersticas son: 1. 2. Permite el intercambio de informacin entre procesos. La comunicacin entre mensajes necesita de un proceso emisor, de un proceso receptor y la informacin que debe intercambiarse. Las operaciones bsicas son: enviar(destino, mensaje) recibir(origen, mensaje) La comunicacin por mensajes requiere que se establezca un enlace entre el receptor y el emisor. Fuerza la exclusin mutua.
3. 4. 5.
1.1.1 Direccionamiento
Direccionamiento directo
Se especifican emisor y receptor de forma explcita. Ejemplo:
Pgina 6

P enva a Q: - P: send (Q, mensaje) - Q: receive (Q, mensaje) La operacin enviar() incluye una identificacin del proceso destino La operacin recibir() puede incluir la identificacin del proceso origen del mensaje. (Procesos cooperantes) La operacin recibir() tambin puede no saber cul es el proceso origen del mensaje (Como un servicio de impresoras, recibir solicitudes de impresin de cualquier proceso). El parmetro origen se utilizara como respuesta de que el mensaje ha sido recibido. Direccionamiento indirecto.
Los mensajes no se envan directamente al receptor, sino a una cola para su posterior procesamiento. Las colas son llamadas buzones (mail box). Los procesos envan mensajes a un buzn y es un proceso quien toma los mensajes del buzn para su procesamiento. Desacoplamiento del direccionamiento indirecto
Permite flexibilidad en el manejo de mensajes. En este tercer caso la relacin puede ser (1-1) (un proceso enva a un solo buzn). Tambin puede haber (n-1) donde varios procesos envan mensajes a un solo buzn o (1-n) donde un proceso enva mensajes a muchos buzones. Un emisor y un receptor. Es un enlace privado de comunicacin entre dos procesos. Muchos emisores y un receptor. Un proceso ofrece un servicio a muchos procesos. En este caso el buzn se llama puerto, (programas cliente/servidor). Un emisor y muchos receptores. Un mensaje se difunde a un conjunto de procesos receptores. (Upgrade de programas por internet). Muchos emisores y muchos receptores. (envo de e-mails).
1.1.1 Sincronizacin Sistemas Operativos II Pgina 7

Emisor con bloqueo y Receptor con bloqueo. Emisor Sncrono Ambos, tanto receptor como emisor son bloqueados hasta que el mensaje sea entregado. Se llama rendezvous. Permite una sincronizacin fuerte de procesos Ejemplo: Procesos cooperantes. Emisor sin bloqueo y Receptor con bloqueo. Emisor Asncrono El emisor continua su procesamiento, enviando mensajes tan rpido como sea posible. El receptor se bloqueo hasta que llegue el mensaje solicitado Es la combinacin ms til de sincronizacin. Ejemplo: Connect desde un programa Oracle (cliente hacia un Listener Oracle (servidor). Emisor sin bloqueo y receptor sin bloqueo Nadie debe esperar Ejemplo: el MS-Word continua su proceso mientras el servicio de impresin de diversos procesos continan. 1.1.1 Partes de un mensaje Cabecera Tipo de mensaje Proceso destino (buzn, puerto) Proceso Origen (cliente) Longitud del mensaje Informacin de control (prioridad, siguiente mensaje, contador de secuencia) Cuerpo Exclusin mutua Envo sin bloqueo, recepcin con bloqueo Un conjunto de procesos comparten un buzn llamado mutex. El buzn al inicio contiene un mensaje de contenido arbitrario. Un proceso que desea usar la seccin crtica, recibe ese mensaje (quitndose del buzn).
Pgina 8

Puesto que la recepcin es con bloqueo, ningn otro procesos podr ingresar a la seccin crtica (ya que no existe mensajes en el buzn). Una vez que ha usado la seccin crtica, devuelve el mensaje al buzn. As el mensaje sirve como posta entre un mensaje y otro para usar la seccin crtica.
1.1.1 Algoritmo para paso de mensajes mediante exclusin mutua /* programa exclusion mutua*/ const int n = /*numero procesos*/ void P(int i) { message msg; while (true) { recibir(mutex,msg); /*seccion critica*/ enviar(mutex,msg); /*el resto de codigo*/ } } void main() { crear_mailbox(mutex); enviar(mutex,null); parbegin(P(1),P(2) ... P(n)); } En sistemas tipo UNIX, el mecanismo bsico de paso de mensajes dentro de un nodo es el de pipes, con o sin nombre.
Para comunicar procesos entre nodos surge el problema del direccionamiento. A este respecto, los sockets de UNIX soportan dos formas de comunicacin alternativas: identificando un socket dentro del sistema de ficheros (entorno UNIX) o asociando un puerto de
Pgina 9

comunicacin en un nodo concreto (entorno Internet). En este ltimo caso se hace precisa la gestin explcita del direccionamiento. Modo de comunicacin. En sistemas distribuidos es de gran inters el soporte de primitivas de paso de mensajes de 1:N. El broadcast o difusin permite enviar un mensaje a todas las direcciones accesibles por el emisor, y se usa en redes locales. Un caso particular de broadcast, el multicast, permite seleccionar un subconjunto de direcciones a las que enviar el mensaje. El soporte para multicast es muy til en sistemas replicados. Como ejemplo, el protocolo IP reserva un conjunto de direcciones para multicast.
1.1.2 Paso de mensajes entre procesos de Windows En la plataforma Windows tanto para la comunicacin entre procesos como para el manejo de eventos se usa un sistema de mensajes. Una de las caractersticas del sistema de mensajes de Windows es no disponer de autentificacin, se puede aprovechar este hecho para simular eventos en los programas que se estn ejecutando y de esta forma controlarlos desde el API de mensajes. Se puede por tanto manejar un programa de forma automtica desde otro, con las posibilidades que ello ofrece. Orientndolo a la ingeniera inversa se puede hacer fuzzing a programas que tan solo admiten entradas desde la interfaz grfica. Supongamos que tenemos un programa cuya ventana principal se llama Sistemas Operativos II Pgina 10

"Form1" y un botn con el texto "Boton" en el cual al hacer clic en un botn muestra un mensaje. 1. ... 2. private void button_Click(object sender, EventArgs e){ 3. MessageBox.Show("Wow!", "Clicked", MessageBoxButtons.OK, Mes sageBoxIcon.Information);
4. } 5. ... Podemos simular que hacemos clic en ese botn si desde otro programa hacemos lo siguiente. 1. using System; 2. using System.Collections.Generic; 3. using System.ComponentModel; 4. using System.Data; 5. using System.Drawing; 6. using System.Linq; 7. using System.Text; 8. using System.Windows.Forms; 9. using System.Runtime.InteropServices; 10. 11.namespace WFuzzing{ 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Sistemas Operativos II Pgina 11 [DllImport("user32.dll", CharSet = CharSet.Auto)] [return: MarshalAs(UnmanagedType.Bool)] static extern bool EnumChildWindows(IntPtr hwndParent, Enum WindowsProc lpEnumFunc, IntPtr lParam); public delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr para meter); [DllImport("user32.dll", CharSet = CharSet.Auto)] public static extern int SendMessage(int hWnd, uint Msg, long w Param, long lParam); public partial class Form2 : Form{ [DllImport("user32.dll", CharSet = CharSet.Auto)] public static extern IntPtr FindWindow(string strClassName, strin g strWindowName);

24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53.
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)] static extern int GetWindowText(IntPtr hWnd, StringBuilder lpStri ng, int nMaxCount); public const int WM_LBUTTONDOWN = 0x0201; public const int WM_LBUTTONUP = 0x0202; public Form2(){ InitializeComponent(); } private void fuzzbutton_Click(object sender, EventArgs e){ IntPtr wHandle = FindWindow(null, "Form1"); List<IntPtr> result = new List<IntPtr>(); GCHandle listHandle = GCHandle.Alloc(result); EnumWindowsProc childProc = new EnumWindowsProc(Enum Window); EnumChildWindows(wHandle, childProc, GCHandle.ToIntPtr(lis tHandle)); } private static bool EnumWindow(IntPtr handle, IntPtr pointer){ StringBuilder text = new StringBuilder(256); ; GetWindowText(handle, text, text.Capacity); if(text.ToString() == "Boton"){ long lngResult = SendMessage(handle.ToInt32(), WM_LBUT TONDOWN, 0, 0); long lngResult2 = SendMessage(handle.ToInt32(), WM_LBU TTONUP, 0, 0); } return true; } }
54.}
Pgina 12

Se le mandan dos mensajes, el primero el de hacer clic con el ratn y el segundo el de levantar el dedo del ratn. Al ejecutar ese cdigo el primer programa debera mostrar el mismo mensaje que si hacemos clic en el botn. De forma similar, se puede automatizar la bsqueda de fallos en programas de los cuales no disponemos del cdigo fuente, tan solo manipulando la interfaz, rellenando campos de texto, activando y desactivando controles, todo de forma automtica.
1.1.1 Paso de mensajes en Linux (Unix) Las colas de mensajes, junto con los semforos y la memoria compartida son los recursos compartidos que pone unix a disposicin de los programas para que puedan intercambiarse informacin. En C para unix es posible hacer que dos procesos (dos programas) distintos sean capaces de enviarse mensajes (estructuras de datos) y de esta forma pueden intercambiar informacin. El mecanismo para conseguirlo es el de una cola de mensajes. Los procesos introducen mensajes en la cola y se van almacenando en ella. Cuando un proceso extrae un mensaje de la cola, extrae el primer mensaje que se introdujo y dicho mensaje se borra de la cola. Tambin es posible hacer "tipos" de mensajes distintos, de forma que cada tipo de mensaje contiene una informacin distinta y va identificado por un entero. Por ejemplo, los mensajes de tipo 1 pueden contener el saldo de una cuenta de banco y el nmero de dicha cuenta, los de tipo 2 puden contener el nombre de una sucursal bancaria y su calle, etc. Los procesos luego pueden retirar mensajes de la cola selectivamente por su tipo. Si un proceso slo est intersado en saldos de cuentas, extraera nicamente mensajes de tipo 1, etc. La forma de conseguir una cola de mensajes en un programa es la siguiente:
En primer lugar necesitamos conseguir una clave, de tipo key_t, que sea comn para todos los programas que quieran compartir la cola de mensajes. Para ello existe la funcin key_t ftok (char *, int). A dicha funcin se le pasa un fichero que exista y sea accesible y un entero. Con ellos construye una clave que nos devuelve. Si todos los programas utilizan el mismo fichero y el mismo entero, obtendrn la misma clave. Es habitual como primer parmetro pasar algn fichero del sistema que sepamos seguro de su existencia, como por ejemplo "/bin/ls", que es el "ls" del unix.
Pgina 13

Para el entero, bastara con poner un #define en algn fichero.h de forma que todos los programas que vayan a utilizar la misma cola incluyan dicho fichero y utilicen como entero el del #define.
Una vez obtenida la clave, se crea la cola de mensajes. Para ello est la funcin int msgget (key_t, int). Con dicha funcin creamos la cola y nos devuelve un identificador para la misma. Si la cola correspondiente a la Clave key_t ya estuviera creada, simplemente nos dara el identificador de la misma (siempre y cuando los parmetros no indiquen lo contrario). El primer parmetro es la clave key_t obtenida anteriormente y que debera ser la misma para todos los programas. El segundo parmetro son unos flags. Aunque hay ms posibilidades, lo imprescindible es:
9
bits menos significativos, son permisos de lectura/escritura/ejecucin para propietario/grupo/otros, al igual que los ficheros. Para obtener una cola con todos los permisos para todo el mundo, debemos poner como parte de los flags el nmero 0777. Es importante el cero delante, para que el nmero se interprete en octal y queden los bits en su sitio (En C, cualquier nmero que empiece por cero, se considera octal). El de ejecucin no tiene sentido y se ignora. se debe crear la cola en caso de que no exista. Si est puesto, la cola se crear si no lo est ya y se devolver el identificador. Si no est puesto, se intentar obtener el identificador y se obtendr un error si no est ya creada.
IPC_CREAT. Junto con los bits anteriores, este bit indica si
En resumen, los flags deberan ser algo as como 0777 | IPC_CREAT
Ya estamos en condiciones de utilizar la cola de mensajes. Para meter un mensaje en la cola, se utiliza la funcin msgsnd (int, struct msgbuf *, int, int)
El primer parmetro entero es el identificador de la cola
obtenido con msgget().

El segundo parmetro es el mensaje en s. El mensaje
debe ser una estructura cuyo primer campo sea long. En dicho long se almacena el tipo de mensaje. El resto de los campos pueden ser cualquier cosa que se desee enviar (otra estructura, campos sueltos, etc). Al pasar el mensaje como parmetro, se pasa un puntero al mensaje y se le hace un "cast" a struct msgbuf. No hay ningn problema

en este "cast" siempre y cuando el primer campo del mensaje sea long.
El tercer parmetro es el tamao en bytes del mensaje
exceptuando el long, es decir, el tamao en bytes de los campos con la informacin.

El
cuarto parmetro son flags. Aunque hay varias opciones, la ms habitual es poner un 0 o bien IPC_NOWAIT. En el primer caso la llamada a la funcin queda bloqueada hasta que se pueda enviar el mensaje. En el segundo caso, si el mensaje no se puede enviar, se vuelve inmediatamente con un error. El motivo habitual para que el mensaje no se pueda enviar es que la cola de mensajes est llena.
Para recoger un mensaje de la cola se utiliza la funcin msgrcv (int, struct msgbuf *, int, int, int).
El primer parmetro es el identificador de la cola obtenido
con msgget().
El segundo parmetro es un puntero a la estructura
donde se desea recoger el mensaje. Puede ser, como en la funcin anterior, cualquier estructura cuyo primer campo sea un long para el tipo de mensaje.
El tercer parmtro entero es el tamao de la estructura
exceptuando el long. El cuarto parmetro entero es el tipo de mensaje que se quiere retirar. Se puede indicar un entero positivo para un tipo concreto o un 0 para cualquier tipo de mensaje.
El quinto parmetro son flags, que habitualmente puede
ser 0 o bien IPC_NOWAIT. En el primer caso, la llamada a la funcin se queda bloqueada hasta que haya un mensaje del tipo indicado. En el segundo caso, se vuelve inmediatamente con un error si no hay mensaje de dicho tipo en la cola.
Una vez terminada de usar la cola, se debe liberar. Para ello se utiliza la funcin msgctl (int, int, struct msqid_ds ). Es una funcin genrica para control de la cola de mensajes con posibilidad de varios comandos. Aqu slo se explica como utilizarla para destruir la cola.
El primer parmetro es el identificador de la cola de
mensajes, obtenido con msgget().

El segundo parmetro es el comando que se desea
ejecutar sobre la cola, en este caso IPC_RMID.


El tercer parmtro son datos necesarios para el comando
que se quiera ejecutar. En este caso no se necesitan datos y se pasar un NULL.

1. Co
Pgina 16

2. nsultar y escribir soluciones al problema de la cena de filsofos

1. Consultar y escribir soluciones al problema de la cena de filsofos
2.1PLANTEAMIENTO DEL PROBLEMA
Cinco filsofos se sientan alrededor de una mesa, cada filsofo tiene un plato de fideos y un tenedor a la izquierda de su plato. Para comer los fideos son necesarios dos tenedores y cada filsofo solo puede tomar los que estn a la izquierda y derecha. Si cualquier filsofo coge un tenedor y el otro est ocupado, se quedar esperando con el tenedor en la mano, hasta que pueda coger el otro tenedor, para luego empezar a comer. 2.2Condiciones Si dos filsofos adyacentes intentan tomar el mismo tenedor a la vez, se produce una condicin de carrera: ambos compiten por tomar el mismo tenedor y no de ellos se queda sin comer. Si todos los filsofos cogen el tenedor que est a su derecha al mismo tiempo, entonces todos se quedarn esperando eternamente, porque alguien debe liberar el tenedor que les falta. Nadie lo har porque todos se encuentran en la misma situacin (esperando que alguno

deje sus tenedores). Entonces los filsofos se morirn de hambre. Este bloqueo mutuo se denomina interbloqueo o deadlock. El problema consiste en encontrar un algoritmo que permita que los filsofos nunca se mueran de hambre. Este es uno de los problemas que representan de una manera ms clara el problema de sincronizacin de procesos en un sistema operativo. 2.3Algoritmo Un algoritmo que permita comer de manera igualitaria a todos los filsofos sera la siguiente: #define N 5 void filsofo (int i) { while (1) { pensar (); /*el filsofo esta pensando*/ /*determina el nmero de filsofos*/ /*i qu filsofo (desde 0 hasta N-1)*/
coger_tenedor(i); /*coge el tenedor izquierdo*/ coger_tenedor[(i+1) %N] comer (); dejar_tenedor(i); /*deja el tenedor izquierdo en la mesa*/ dejar_tenedor((i+1) %N) mesa*/ } } Este algoritmo muestra un problema en coger_tenedor ya que si los filsofos cogen sus tenedores izquierdos de forma simultnea, ninguno podr coger su tenedor derecho lo que producira un interbloqueo. /*deja el tenedor derecho en la /*coge el tenedor derecho*/
Pgina 18

Por lo que se podra modificar el programa para que despus de que tomen el tenedor izquierdo, el programa verifique si est disponible el tenedor derecho; caso contrario el filsofo deja el tenedor izquierdo, espera cierto tiempo y vuelve a repetir el proceso. #define N #define IZQ derecha*/ #define DER izquierda*/ #define PENSANDO 5 /*nmero de filsofos*/ (i-1) %N (i+1) %N 0 /*numero del vecino de izquierda a /*numero del vecino de derecha a /*el filsofo esta pensando*/ /*el filsofo esta hambriento*/ /*el filsofo esta comiendo*/ /*vector que lleva el estado de los /*vector que lleva el estado de los /*un semforo por filsofo*/ /*i: de que filosofo se trata desde 0
#define HAMBRIENTO 1 #define COMIENDO int estado [N]; filsofos*/ semaforo exmut=1; filsofos*/ semaforo s[N]; void filosofo (int i) hasta N-1)*/ { while (1){ pensar(); coger_tenedores(i); bloquendose si no puede*/ comer(); dejar_tenedores(i); mesa*/ } 2
/*se ejecuta eternamente*/ /*el filosofo esta pensando*/ /*obtiene dos tenedores,
/*deja
ambos
tenedores
en
la
Pgina 19

Esta propuesta de solucin al problema de los filsofos tambin falla, puesto que todos los filsofos podran empezar el algoritmo de forma simultnea, por lo que cogeran sus tenedores izquierdos, vera que los derechos no estn disponibles, esperaran, volveran a coger sus tenedores izquierdos simultneamente, como un bucle que se repite eternamente. A esto se lo conoce como aplazamiento indefinido.
2.4 Solucin al problema
Una mejora al algoritmo anterior es la proteccin de los cinco enunciados siguientes a la llamada al procedimiento pensar mediante un semforo binario exmut. Antes de empezar a coger los tenedores uno de los filsofos hara un wait sobre exmut. Desde el punto de vista terico esta solucin es adecuada. Desde el punto de vista prctico presenta un error de eficiencia; en todo instante existir a los mucho un filsofo comiendo. Si se dispone de cinco tenedores, se debera permitir que dos filsofos comieran al mismo tiempo. Otra solucin para el nmero arbitrario de filsofos, utiliza un vector, estado, para llevar un registro de la actividad de un filsofo: si est comiendo, pensando o hambriento (estado que indica que quiere coger los tenedores). Un filsofo puede comer nicamente si los vecinos no estn comiendo. Los vecinos del i-simo filsofo se definen en los marcos IZQ y DER; si i=2, entonces IZQ=1, y DER=3. El programa utiliza un vector de semforos, uno por filsofo, de forma que los filsofos hambrientos puedan bloquearse si los tenedores necesarios estn ocupados. Cada proceso filsofo se ejecuta como un programa principal; pero los procedimientos coger tenedores, dejar_tenedores y prueba son procedimientos ordinarios y no procesos separados, tal como se muestra en el siguiente algoritmo.
Void coger_tenedores(int) hasta N-1*/ { wait(&exmut); /*entra en la seccin crtica*/ /*i de qu filsofo se trata( desde0
Pgina 20

estado [i]=HAMBRIENTO hambre*/ prueba(i); signal (&exmut); wait(&s(i)); tenedores*/ } void dejar_tenedores (int i) hasta N-1*/ { wait(&exmut); estado(i)=PENSANDO; ha dejado de comer*/ prueba (IZQ); puede comer ahora*/ prueba(DER); puede comer ahora*/ signal (&exmut); } void prueba(int i) 1)*/ {
/*registra el hecho de que el filsofo i tiene /*intenta coger dos tenedores*/ /*sale de la seccin crtica*/ /*se bloquea si no consigue los dos
/*i de que filsofo se trata (desde 0
/*entra en la seccin crtica*/ /*registra el hecho de que el filsofo i /*comprueba si el vecino izquierdo /*comprueba si el vecino derecho /*sale de la seccin crtica*/
/*i de que filosofo se trata desde 0 hasta N-
If estado(i)==HAMBRIENTO && estado(IZQ) = COMIENDO && estado(DER)! =COMIENDO) { estado (i) = COMIENDO signal(&a(i)); } }
Pgina 21

Nota: consideramos una seccin crtica a la accin de comer. Espera activa: listo para entrar en accin pero necesita liberar recursos (proceso concurrente). Existen diferentes soluciones para todos los tipos de inconvenientes dentro de este proceso que simula una sincronizacin de procesos dentro de un sistema operativo, estos son los siguientes: Turno cclico
Empezamos por un filsofo que si quiere, puede comer y despus pasa su turno al de la derecha. Cada filsofo comera en el turno que le corresponde. Problema: si el nmero de filsofos es mayor, uno de ellos puede morir de hambre mientras espera su turno. Varios turnos
Se establecen turnos para cada uno de los filsofos, con su respectivo turno una vez que haya comido pasa su turno al de la derecha; se colocaran turnos en posiciones alternas (entre dos de las fichas quedaran dos filsofos). Cada uno tiene su respectivo tiempo para ingerir el alimento y en volver a tener hambre, el tiempo de turno establecido puede hacer que sea la peor solucin que la anterior. Si el tiempo de tuno se aproxima al tiempo medio que tarda un filsofo en comer esta variante da muy buenos resultados. Adems se considera que si el tiempo medio en comer es similar al tiempo medio en volver a tener hambre la solucin se aproxima al ptimo. Colas de tenedores
Si uno de los filsofos quiere comer, se pone en la cola de los dos tenedores que necesita. Cuando un tenedor est libre los toma, si toma los dos tenedores come y deja libre los dos tenedores. Cada tenedor slo puede tener dos filsofos en cola, siempre los mismos.
Pgina 22

Problema: si todos quieren comer a la vez y todos empiezan tomando el tenedor de su derecha se bloquea el sistema; esto se le conoce como deadlock. Resolucin: cuando un filsofo tiene un tenedor espera un tiempo aleatorio para conseguir el segundo tenedor. Si en ese tiempo no queda libre el segundo tenedor, suelta el que tiene y vuelve a ponerse en cola para sus dos tenedores. Si un filsofo suelta un tenedor (porque ha comido o porque ha esperado demasiado tiempo con el tenedor en la mano) pero todava desea comer, vuelve a ponerse en cola para ese tenedor. Si el filsofo adyacente est ya en esa cola de tenedor (tiene hambre) lo toma y si no vuelve a cogerlo el otro filsofo.
Pgina 23

3. Bibliografa

1. Bibliografa
http://es.wikipedia.org/wiki/Problema_de_la_cena_de_los_fil %C3%B3sofos http://wwwdi.ujaen.es/~lina/TemasSO/CONCURRENCIA/4Proble masClasicosdeComunicacionentreProcesos.htm 36813802-Problema-de-la-Cena-de-los-Filosofos http://www.ctr.unican.es/asignaturas/procodis_3_II/Doc/Procodis _2_05.pdf file:///E:/Documents%20and%20Settings/Fernanda/Mis %20documentos/sistemas %20operativos/operativos/Mensajes.htm http://www.chuidiang.com/clinux/ipcs/colas.php http://javiyu.blogspot.com/2010/04/paso-de-mensajes-entreprocesos-en.html
Pgina 24

Contenido
1. Facilidades de uso de los monitores y paso de mensajes en sistemas operativos estandares..............................................................1 1.1 1.2 1.3 1.4 1.5 1.6 Monitores........................................................................................1 Sintaxis de un monitor..................................................................1 Aspectos caractersticos de un monitor....................................2 Aspectos de un tipo de monitor...................................................3 Facilidades del uso de monitores:...............................................3 Paso de mensajes en sistemas operativos estndares...........4 Paradigma de paso de mensajes...........................................4 Sistemas de colas de mensajes.............................................5 Direccionamiento.....................................................................6 Sincronizacin..........................................................................7 Partes de un mensaje..............................................................7
1.6.1 1.6.2 1.6.3 1.6.4 1.6.5
1.6.6 Algoritmo para paso de mensajes mediante exclusin mutua 8 1.6.7 1.6.8 Paso de mensajes entre procesos de Windows..................9 Paso de mensajes en Linux (Unix)......................................11
2. Co..........................................................................................................14 3. nsultar y escribir soluciones al problema de la cena de filsofos 15 2.1 2.2 2.3 2.4 PLANTEAMIENTO DEL PROBLEMA..............................................15 Condiciones...................................................................................15 Algoritmo.......................................................................................16 Solucin al problema...................................................................17
3. Bibliografa...............................................................................................21 3. Bibliografa
Pgina 25

Pgina 26

Deberoperativos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Deberoperativos

Transféré par

Droits d'auteur :

Formats disponibles

Fecha de elaboracin: ____Enero 2012____

CARRERA Ingeniera en Informtica y Ciencias de la Computacin TRABAJO 1 TEMA TTULO Consulta

NOMBRE DE LA ASIGNATURA SISTEMAS OPERATIVOS II DURACI N15 das (HORA)

Monitores, paso de mensajes y problema de los filsofos

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

IBM WebSphere Message Broker, MSMQ, Java Message Service

Fecha de elaboracin: ____Enero 2012____

Se especifican emisor y receptor de forma explcita. Ejemplo:

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

IPC_CREAT. Junto con los bits anteriores, este bit indica si

En resumen, los flags deberan ser algo as como 0777 | IPC_CREAT

obtenido con msgget().

Fecha de elaboracin: ____Enero 2012____

exceptuando el long, es decir, el tamao en bytes de los campos con la informacin.

mensajes, obtenido con msgget().

ejecutar sobre la cola, en este caso IPC_RMID.

Fecha de elaboracin: ____Enero 2012____

El tercer parmtro son datos necesarios para el comando

que se quiera ejecutar. En este caso no se necesitan datos y se pasar un NULL.

Fecha de elaboracin: ____Enero 2012____

2. nsultar y escribir soluciones al problema de la cena de filsofos

2.1PLANTEAMIENTO DEL PROBLEMA

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

/*i de que filsofo se trata (desde 0

/*i de que filosofo se trata desde 0 hasta N-

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

Fecha de elaboracin: ____Enero 2012____

1.6.1 1.6.2 1.6.3 1.6.4 1.6.5

Fecha de elaboracin: ____Enero 2012____

Vous aimerez peut-être aussi

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012

Fecha de elaboracin: Enero 2012