proyecto final de sisope t3

UUNNIIVVEERRSSIIDDAADD PPRRIIVVAADDAA DDEELL NNOORRTTEE

LLaauurreeaattee IInntteerrnnaacciioonnaall UUnniivveerrssiittiieess ®®

““PPRROOYYEECCTTOO FFIINNAALL TT33””

CCUURRSSOO

SSiisstteemmaass OOppeerraattiivvooss

PPRREESSEENNTTAA

CCaabbrreerraa GGuueevvaarraa,, AAlleexxaannddeerr RRaaúúll

SSoolliieerr PPrraaddoo,, JJoonnaatthhaann MMiicchhaaeell

DDOOCCEENNTTEE

IInngg.. AAlleejjaannddrroo HHuuggoo PPéérreezz QQuuiirroozz

CCaajjaammaarrccaa,, JJuulliioo ddeell 22001122




CCUURRSSOO


PPRREESSEENNTTAA



DDOOCCEENNTTEE






CCUURRSSOO


PPRREESSEENNTTAA



DDOOCCEENNTTEE



~ 2 ~UNIVERSIDAD PRIVADA DEL NORTELaureate International Universities®

““UUNNIIXX eess uunn SSiisstteemmaa OOppeerraattiivvoo sseenncciilllloo.. SSoolloo qquuee hhaayy qquuee sseerr uunn ggeenniioo ppaarraa ccoommpprreennddeerr ssuu sseenncciilllleezz””

ANÓNIMO

ÍÍNNDDIICCEEII.. AALLGGOORRIITTMMOOSS

11.. CClliieennttee // SSeerrvviiddoorr ...................................................... PPáágg.. 0044

22.. PPrroocceessoo ccoonn MMúúllttiipplleess HHeebbrraass .................................. PPáágg.. 0055

33.. PPrroodduuccttoorr yy CCoonnssuummiiddoorr .............................................. PPáágg.. 0066

44.. BBuuffffeerr CCiirrccuullaarr ............................................................ PPáágg.. 0077

55.. SSeemmááffoorrooss ........................................................................ PPáágg.. 0088

66.. AAllggoorriittmmoo ddeell BBaannqquueerroo .............................................. PPáágg.. 0099

IIII.. IINNVVEESSTTIIGGAACCIIÓÓNN

11.. PPrroobblleemmaass CClláássiiccooss ddee SSiinnccrroonniizzaacciióónn .................. PPáágg.. 1111

aa.. PPrroobblleemmaa ddeell BBúúffeerr LLiimmiittaaddoo .............................. PPáágg.. 1111

bb.. EEll pprroobblleemmaa ddee llooss LLeeccttoorreess--EEssccrriittoorreess ........ PPáágg.. 1111

cc.. PPrroobblleemmaa ddee llaa CCeennaa ddee llooss FFiillóóssooffooss ............ PPáágg.. 1133

22.. MMoonniittoorreess eenn llaa SSiinnccrroonniizzaacciióónn ddee PPrroocceessooss ...... PPáágg.. 1155



ANÓNIMO



ANÓNIMO

I. Cliente / ServidorLa implementación del Programa Servidor Sigue las Siguientes Ideas:

1. Se Inicia el Servidor

2. El Servidor se mantiene escuchando cualquier petición de un cliente para

conectarse.

3. El Servidor acepta al Cliente.

4. El servidor lanza un Hilo de Comunicación con el Cliente.

5. Por el Hilo se envían y reciben Mensajes a través del Servidor entre todos los

Clientes.

6. Si el Cliente cierra la Comunicación el Hilo se rompe y se corta la

Comunicación con ese Cliente.

La Implementación del programa Cliente Sigue las Siguientes Ideas:

1. Se Inicia el Cliente

2. El Cliente lanza una petición al Servidor para conectarse

3. El Servidor asigna un Hilo al cliente al ser Aceptado.

4. El Cliente envía y recibe mensajes por el hilo hacia todos o hacia algún usuario

específico, usando al servidor como puente para las comunicaciones.

Para esto se ha empleado objetos de la clase ServerSocket y Socket para el

servidor y cliente respectivamente que permiten la conexión entre cliente y servidor

mientras que los Hilos sirven para hacer que el servidor se mantenga escuchando y

no interrumpa su proceso mientras los clientes se comunican a través de

mensajes.

Sockets: Los sockets no son más que puntos o mecanismos de

comunicación entre procesos que permiten que un proceso hable (emita o reciba

información) con otro proceso incluso estando estos procesos en distintas

máquinas. Esta característica de interconectividad entre máquinas hace que el

concepto de socket nos sirva de gran utilidad.



ANÓNIMO

II. Proceso con Múltiples HebrasUn proceso en Amoeba consiste de uno o más hebras que se ejecutan en

paralelo. Todas las hebras de un proceso comparten el mismo espacio de

direccionamiento, pero cada uno tiene una porción dedicada de ese espacio para

utilizar como su pila privada, cada una tiene su propio contador de programa. Desde

el punto de vista del programador, cada hebra es como un proceso secuencial,

excepto que las hebras de un proceso pueden comunicarse utilizando memoria

compartida, para conseguir esto, las hebras pueden sincronizarse entre sí

utilizando semáforos.

El propósito de tener múltiples hebras en unos procesos es aumentar el

desempeño a través del paralelismo, y proveer aun un modelo semántico razonable

para el programador.

Por ejemplo, un servidor de archivos puede ser programado como un

proceso con múltiples hebras, Cuando llega un pedido, este puede ser asignado a

alguna de las hebras para manejarlo.

Esa hebra primero revisa un cache interno para ver si es que se encuentra

el dato solicitado. Mientras espera la respuesta del disco, la hebra queda bloqueada

y no podrá manejar ningún otro pedido. De todos modos, estos nuevos pedidos

pueden ser asignados a otras hebras en el mismo proceso para trabajar mientras

que la primera hebra del proceso se encuentra bloqueada. De este modo, múltiples

pedidos pueden ser manejados de manera simultánea, permitiendo que cada hebra

trabaje de manera secuencial.

Cuando una hebra se bloquea ya sea porque no tiene trabajo que hacer o

porque está esperando una respuesta remota, se llama al planificador, la hebra

queda bloqueada y una nueva hebra puede iniciar su ejecución.



ANÓNIMO

III. Productor y ConsumidorEl problema Productor/Consumidor consiste en el acceso concurrente por

parte de procesos productores y procesos consumidores sobre un recurso común

que resulta ser un buffer de elementos. Los productores tratan de introducir

elementos en el buffer de uno en uno, y los consumidores tratan de extraer

elementos de uno en uno.

Para asegurar la consistencia de la información almacenada en el buffer, el

acceso de los productores y consumidores debe hacerse en exclusión mutua.

Adicionalmente, el buffer es de capacidad limitada, de modo que el acceso por parte

de un productor para introducir un elemento en el buffer lleno debe provocar la

detención del proceso productor. Lo mismo sucede para un consumidor que intente

extraer un elemento del buffer vacío.

Dos procesos comparten un mismo BUFFER de espacio limitado. El

consumidor coloca información y el otro la saca, pudiéndose generalizar a N

productores y consumidores. Cuando el productor quiere agregar un elemento,

pero el BUFFER está lleno, debe dormir hasta que el consumidor saque un elemento

y entonces puede seguir agregando elementos. Igualmente si el consumidor no

tiene elementos que extraer del BUFFER, entonces duerme hasta que el productor

coloque elementos.

Se da un problema porque por ejemplo, al estar vacío el BUFFER, el

consumidor está evaluando su contador y ve que no hay datos, pero antes de

dormirse el CPU pasa a ejecutar al productor, este pone un dato y despierta al

consumidor, sin embargo como el Consumidor no llego a dormirse al reanudarse se

duerme y el productor continua produciendo. Tarde o temprano el productor habrá

llenado el BUFFER. Un arreglo es agregar un bit de espera donde si un proceso

quiere despertar a uno que nunca se durmió, este bit evita que caiga de nuevo al

Sleep(), pero esta solución se vuelve difícil de implementar con varios procesos y

muchos bits de espera.



ANÓNIMO

IV. Buffer CircularEl método que vamos a emplear en este ejemplo para minimizar el tiempo de

espera que sufren los subprocesos que comparten recursos es crear un búfer

circular. Con este nuevo enfoque, en vez de tener una única variable compartida,

tendremos un arreglo de búferes. De esta forma, si el productor produce valores a

mayor velocidad de la que el consumidor pueda consumirlos, almacenará los

valores en posiciones distintas del arreglo (mientras haya espacio). Esto permite al

productor hacer su tarea, aún cuando el consumidor no esté listo para realizar la

suya. De igual forma, si en ciertas ocasiones el consumidor recoge valores a mayor

velocidad de la que el productor pueda consumirlos, este puede buscar otros

valores adicionales en el arreglo (si los hay) que el productor pudo haber producido

con anterioridad.

Observa además, querido lector, que usar un búfer circular sería inapropiado

si los procesos se ejecutan a diferentes velocidades conscientemente. Es decir, si

por ejemplo sabemos que el consumidor se ejecuta siempre a mayor velocidad, no

necesitaríamos espacios adicionales puesto que el productor no tendría tiempo de

llenarlas. De igual forma, si el productor se ejecutase siempre a mayor velocidad

que el consumidor, necesitaríamos un arreglo con infinitas posiciones.



ANÓNIMO











con anterioridad.









ANÓNIMO











con anterioridad.









ANÓNIMO

V. SemáforosUn semáforo binario es un indicador (S) de condición que registra si un

recurso está disponible o no. Un semáforo binario sólo puede tomar dos valores: 0 y

1. Si, para un semáforo binario, S = 1 entonces el recurso está disponible y la tarea

lo puede utilizar; si S = 0 el recurso no está disponible y el proceso debe esperar.

La operación inicializa se debe llevar a cabo antes de que comience la

ejecución concurrente de los procesos ya que su función exclusiva es dar un valor

inicial al semáforo. Un proceso que corre la operación espera y encuentra el

semáforo a 1, lo pone a 0 y prosigue su ejecución. Si el semáforo está a 0 el

proceso queda en estado de espera hasta que el semáforo se libera. Dicho estado

se debe considerar como uno más de los posibles de un proceso. Esto es así debido

a que un proceso en espera de un semáforo no está en ejecución ni listo para pasar

a dicho estado puesto que no tiene la CPU ni puede pasar a tenerla mientras que

no se lo indique el semáforo. Tampoco es válido el estado suspendido, ya que este

estado está pensado para que lo utilicen llamadas al sistema operativo para

suspender o reactivar un proceso que no tiene por qué tener una conexión con los

semáforos. El diagrama de transición de estados de la figura se puede ampliar con

un nuevo estado que denominamos de espera.



ANÓNIMO

VI. Algoritmo del BanqueroEl Algoritmo del banquero, en sistemas operativos es una forma de evitar el

interbloqueo, propuesta por primera vez por Edsger Dijkstra. Es un acercamiento

teórico para evitar los interbloqueos en la planificación de recursos. Requiere

conocer con anticipación los recursos que serán utilizados por todos los procesos.

Esto último generalmente no puede ser satisfecho en la práctica.

Este algoritmo usualmente es explicado usando la analogía con el

funcionamiento de un banco. Los clientes representan a los procesos, que tienen un

crédito límite, y el dinero representa a los recursos. El banquero es el sistema

operativo.

El banco confía en que no tendrá que permitir a todos sus clientes la

utilización de todo su crédito a la vez. El banco también asume que si un cliente

maximiza su crédito será capaz de terminar sus negocios y devolver el dinero a la

entidad, permitiendo servir a otros clientes.

El algoritmo mantiene al sistema en un estado seguro. Un sistema se

encuentra en un estado seguro si existe un orden en que pueden concederse las

peticiones de recursos a todos los procesos, previniendo el interbloqueo. El

algoritmo del banquero funciona encontrando estados de este tipo.

Los procesos piden recursos, y son complacidos siempre y cuando el

sistema se mantenga en un estado seguro después de la concesión. De lo

contrario, el proceso es suspendido hasta que otro proceso libere recursos

suficientes.



ANÓNIMO



ANÓNIMO

I. Problemas Clásicos de Sincronización

a. Problema del Búfer LimitadoEste problema nos dice que un productor por ejemplo no puede seguir

ejecutándose por no tener espacio en memoria, esto pasa por razón del

consumidor, ya que no se consumen los datos de memoria que el productor está

llenando.

b.El Problema de los Lectores-EscritoresEl problema nos dice que hay un recurso utilizado por varios procesos

(lectores y escritores); este recurso solo puede ser usado por un proceso, si el

recurso esta libre la prioridad será para el escritor. Cada proceso tiene 1

semáforo, estos semáforos tienen valor binario siendo 1 cuando el recurso esta

libre y 0 cuando el recurso está siendo utilizado.

Esto se soluciona implementando un algoritmo para el manejo de los

semáforos y la memoria compartida. Las condiciones a cumplir para este

problema son:



ANÓNIMO





llenando.








problema son:



ANÓNIMO





llenando.








problema son:



ANÓNIMO

* No se puede dejar en espera a ningún proceso de lectura, si ningún proceso

escritor accede al recurso.

* Cuando un escritor va a realizar su tarea los lectores no pueden interferir.

El algoritmo es el siguiente:



ANÓNIMO







ANÓNIMO







ANÓNIMO

c. Problema de la Cena de los FilósofosPlanteado en 1985 por Edsger Dijkstra; el problema nos dice que 5

filósofos están sentados en una mesa, cada uno con un plato de comida con un

tenedor a su izquierda, para poder comer la condición es comer con 2

tenedores.

Si dos filósofos adyacentes quieren tomar e mismo tenedor se produce

una condición llamada “condición de carrera”, esta consta de quien tome el

tenedor más rápido come dejando al otro en espera.

Puede darse el caso que todos por ejemplo tomen el tenedor de su

izquierda, en ese caso tendrían que esperar eternamente, ya que ninguno soltara

el tenedor que tiene por consiguiente morirían de hambre, a eso se llama

interbloqueo.

A continuación le vamos a presentar algunas soluciones a las cuales

recurrir estas son:

Turno cíclico: Cada filósofo tiene un turno en que puede comer, al acabar

pasaría su turno al siguiente de su derecha y así sucesivamente, el problema

recaería en que si la cantidad de filósofos es demasiado grande mueran de

hambre antes de llegar su turno.

Varios turnos: Se establecen varios turnos. Para hacerlo más claro

supongamos que cada filósofo que puede comer es su turno, que después

pasa a la derecha, dando solo un tiempo límite para que coma. El problema

que podría ocurrir es el tiempo que el filosofo demora en comer, ya que puede

ser que el tiempo para comer y el tiempo en que le da hambre no concuerden

con su turno y muera de hambre.



ANÓNIMO

Colas de tenedores: Para el uso de los tenedores se tiene que hacer una cola,

cada filosofo tiene que hacer 2 colas para poder comer, solo 2 filósofos

pueden estar en la cola por un tenedor, el problema es el explicado

anteriormente que todos cojan digamos que el tenedor de la derecha al

mismo tiempo, todos morirían de hambre ya que nadie soltaría el tenedor que

tiene. Una manera de solucionar esto es dar un tiempo determinado de que

cada filósofo tenga un tenedor si no consigue los 2 e ese tiempo deja el

tenedor que cogió y se pone nuevamente en cola de espera de los 2

tenedores.

El portero del comedor: la solución dada acá es que se ponga un control en la

entrada del comedor haciendo que solo n-1 filósofos entren así por lo menos

1 de los filósofos comería si o si.

Nosotros plantearemos un algoritmo para solucionar este problema y los

filósofos no mueran de hambre el cual consta del siguiente código:

Como podemos ver se implementa un semáforo a cada filosofo, esto lo

hacemos para que los filósofos hambrientos y no tengan oportunidad de comer

se bloqueen.

Filosofo ejemplonúmero de filósofos i;

filosofo i;filosofo pensando;

si (coger 2 tenedores);filosofo comiendo;soltar 2 tenedores;

no(coger 2 tenedores);espera tenedores

fin;



ANÓNIMO

II. Monitores en la Sincronización de ProcesosSon una especie de datos abstractos, estos contienen un conjunto de

procedimientos de control (solo una parte de estos son visibles) y otro de datos

privados; el acceso al monitor está permitido solamente a través de el

compilador y los procesos públicos que estos tienen.

Una desventaja del uso de los monitores es la exclusividad de su uso, con

esto queremos decir que la concurrencia está limitada si muchos procesos

hacen uso del mismo monitor. La sincronización condicional se puede encontrar

en muchas implementaciones de monitores, esta trata de la exclusión mutua,

dando paso a otro proceso liberando el cerrojo del proceso que esté ejecutando,

el proceso liberador del cerrojo es bloqueado hasta que otro proceso lo

despierte por así decirlo.

monitor ejemplointeger i;condition c;

procedure productor ();end;

procedure consumidor ();end;

end monitor;

proyecto final de sisope t3

Technology