PRACTICA:

4.2

NOMBRE:

INTERPRETE DE MANDATOS CON TUBERIAS

OBJETIVO DE LA PRACTICA:

Complementar la funcionalidad de la practica 2.7 incluyendo la funcionalidad necesaria para la ejecución de secuencias de mandatos conectados a través de tuberías

DESCRIPCION:

La practica a desarrollar tiene que completar la funcionalidad de la practica 2.7 cuyo objetivo era el desarrollo de un interprete de mandatos sencillos. Para el desarrollo de esta práctica debe utilizarse el mismo material de apoyo y misma función obtener mandato descrita en esta practica y que permite obtener el mandato a ejecutar. El alumno debe ampliar la practica 2.7 para permitir la ejecución de mandatos a través de pipes. No hay ninguna restricción en el numero de mandatos que se pueden ejecutar.

FUNCIONALIDAD

• Cerrar el descriptor de lectura de la tubería, no lo debe utilizar.

• Cerrar la salida estándar que inicialmente en un proceso referencia el Terminal.

• Duplicar el descriptor de la tubería mediante la sentencia dup. Esta llamada devuelve y consume un descriptor que será el número más bajo disponible, que coincida con todos los procesos como el descriptor de salida estándar. Con esta operación se consigue que el descriptor de archivo y el de almacenado sirvan para escribir datos en la tubería. De esta manera se conseguiría redirigir el descriptor del proceso estándar en la salida de la tubería.

• Se cierra el descriptos ya que el hijo no lo va utilizar en adelante

• Cuando el proceso hijo invoca el proceso exec para ejecutar un nuevo programa se conserva en el BCP la tabla de descriptores de archivos abiertos.

PROBLEMÁTICA

Fue un poco de problema recompilar la practica 2.7 ya que en el salón de clases no tenia todas las librerías entonces se tuvo que buscar cuales eran las que le hacían falta para finalmente compilarla y por consiguiente se tuvo un poco de problemas en esta por la misma causa edemas de que las maquinas eran muy limitadas y no cumplían con todas las características.

CONCLUSIONES:

En esta práctica aprendimos el concepto de tuberías que yo en particular no sabía además de varios conceptos mas en los que destacan el proceso hijo y otros términos un poco nuevos se tuvo problemas para identificar los comandos además de que se nos proporciona el código en el libro y es un poco difícil de entender al final lo entendimos el concepto es que se tiene que crear otro ejecutor de ordenes que no sea del sistema operativo mas sin embargo que si lo use.

PRACTICA:

4.3

NOMBRE:

PRODUCTOR CONSUMIDOR UTILIZANDO PROCESOS LIGEROS

OBJETIVO DE LA PRACTICA:

Familiarizarse con el uso de procesos ligeros, así como la forma de comunicar esos procesos mediante memoria compartida. También se pretende que se aprenda a resolver el problema de productor consumidor en un caso concreto.

DESCRIPCION:

El programa deberá lanzar dos procesos ligeros uno que ejecute la función consumidor y otro que ejecute la función productor. Para ello se deberá usar la función pthread_create. El programa deberá garantizar la exclusión mutua en el acceso a la cola circular que comparten los dos procesos , es decir hay que evitar que ninguno de los dos proceso accedan a la cola circular. El programa además deberá asimismo evitarla espera activa de los dos procesos mientras comprueban si la cola circular esta está vacía o llena según el caso es decir el proceso deberá esperar a que se cumpla la condición requerida de la forma que deje la CPU libre para otros proceso.

FUNCIONALIDAD

• La función que se implemente genera un numero aleatoria cada cierto tiempo e introduce el numero en una cola circular. En caso de que estuviera llena el consumidor espera que exista una posición libre en dentro de la cola

• La función que implementa el productor examina la cola circular periódicamente si esta vacía espera a que haya algún elemento nuevo en ella; en caso contrario extrae el elemento mas antiguo de la cola circular y pasado por un cierto tiempo que se considera de proceso imprime la cola circular.

• La cola circular se implementa mediante una estructura que contiene un vector de tamaño N donde se almacena los elementos de la cola; así mismo consta de dos enteros inicio__cola y fin_cola que almacenan índices del vector de elementos. El índice inicio_cola indica la posición del vector don de almacena el próximo elemento a introducir en la cola. El índice fin_cola indica la posición de vector donde se encuentra el próximo elemento a extraer.

PROBLEMÁTICA

El principal problema de esta practica fue la falta de entendimiento y que el código no realizaba lo que pedía y no se podía observar para entender así que se le realizaron algunas modificaciones el código entre las cuales se llamaba a la función consumidor y luego ala función productor de manera alternada para no crear conflictos en el momento de ser llamadas otra cosa que se realizo fue la modificación de el proceso consumidor para que se mostrar y se ejecutara fueron las principales problemáticas pero se lograron solucionar y se termino satisfactoriamente el programa

CONCLUSIONES:

Se logra realizar la práctica al momento de correrla se observó que sí funcionó lo que se había implementado que creaba un productor que este llamaba a un consumidor y lo hacía por cierto tiempo que en este caso se le asignaron 3 seg. Mismos que pueden ser modificador con esta practica se aprendía a manejar un poco las llamadas a varios procesos y como hacer que no utilicen la misma variable al mismo tiempo que esto puede dañar un poco la respuesta del sistema.

PRACTICA:

4.4

NOMBRE:

DISEÑO E IMPLEMENTACION DE SEMAFOROS EN EL MINIKERNEL

OBJETIVO DE LA PRACTICA:

El principal objetivo es que se pueda conocer de forma practica como funcionan los semáforos. La funcionalidad típica de los semáforos se le ha añadido una serie de características que hacen que se tenga que enfrentar con los distintos patrones de sincronización entre ellos.

DESCRIPCION:

Se pretende ofrecer a las aplicaciones un servicio de sincronización basado en semáforos. Antes cabe aclara que su semántica esta ideada para permitir practicar con distintas situaciones que aparecen frecuentemente en la programación de un sistema operativo.

FUNCIONALIDAD

• El numero de semáforos es fijo

• Cada semáforo tiene asociado un nombre que consiste en una cadena de caracteres con un tamaño máximo igual a MAX_NOM_SEM incluyendo el carácter nulo

• Cuando se crea un semáforo el proceso obtiene un descriptor que le permite acceder al mismo. Si ya tiene un semáforo con este nombre se devuelve un error. En el caso de que no exista colisión, se debe comprobar si se ha alcanzado el numero máximo de semáforos en el sistema. Si esto ocurre se debe bloquear el proceso hasta que se elimine algún semáforo.

• Para poder acceder a un semáforo ya existente se debe abrir especificando su nombre.

• Cada proceso tiene asociado un conjunto de descriptores asociados a los semáforos que están usando. Si al abrir o crear un semáforo no hay ningún descriptor libre se devuelve un error

• Las primitivas de uso del semáforo tienen básicamente la semántica convencional. Ambas reciben como parámetro para abrir un semáforo la única característica un poco especial es que la primitiva signal incluye como argumento el número de unidades que se incrementa el semáforo

• Cuando un proceso no necesita el semáforo lo cierra y se elimina cuando ningún proceso lo necesita

• Cuando el proceso termina ya sea voluntaria o involuntariamente el sistema operativo debe cerrar todos los semáforos que usaba el proceso.

PROBLEMÁTICA:

En esta practica no un hubo muchos problemas ya que se contaba con el código completo y en dos versiones en hilos y sin hilos

CONCLUSIONES:

El programa fue corrido satisfactoriamente y no hubo muchas complicaciones en esta practica se aprendió el uso del semáforo y se mostró en el al momento de ejecutarse cuando entraba en operación cada semáforo y cuando terminaba además cuando terminaba de ejecutarse cerraba todos los semáforos creados.

PRACTICA:

4.5

NOMBRE:

DISEÑO E IMPLEMENTACION DEL MUTEX EN EL MINIKERNEL

OBJETIVO DE LA PRACTICA:

El objetivo principal de esta practica es que se pueda ver de forma practica la diferencia que hay entre semáforos y mutex.

DESCRIPCION:

Se pretende completar la practica anterior añadiendo un mecanismo de mutex que conviva estrechamente con los semáforos planteados en la practica anterior. De echo, el mutex se va considerar un tipo especial de semáforo generalmente implementados previamente. Concretamente se van a implementar dos tipos de mutex:

Mutex no recursivos: Si un proceso que posee mutex intenta bloquearlo de nuevo se le devuelve un error ya que esta construyendo un caso trivial de interbloqueo

Mutex recursivos: Un proceso que posee un puede bloquearlo nuevamente todas las veces que quiera sin embargo el mutex que puede bloquearlo solo quedara liberado cuando el proceso lo desbloquee tantas veces como lo bloqueo

Se debería generalizar la estructura que contiene los datos de un semáforo definida en la practica anterior para que pueda dar cobijo como a los datos de un semáforo como a los de dos tipos de mutex. Para ello se podría usar un registro variante como el proporcionado por un tipo unio de C.

Dado que tanto los semáforos de tipo general como ambos que de tipo mutex comparten mucha funcionalidad se debera intentar organizar su codigo de manera adecuada para evitar duplicidades.

FUNCIONALIDAD

• En el numero de semáforos disponibles y en el numero de sdescriptores por proceso se van a incluir todos los mecanismos de sincronizacion.

• El nombre del mutex tendra las mismas caracteristicas que las del semáforo; de echo compartiran el mismop espacio de nombres.

• La creación del mutex tendra las mismas caracteristicas que las de un semáforo. Debe comprobar la posible Colision de nombre

• La primitiva para abrir un mutex va a tener las mismas caracteristicas que la de los semáforos

• Las primitivas lock y un lock tienen el comportamiento convencional

• La semántica asociada a el cierre de un meutex ti ene un importante diferencia con respecto alo semáforos. En este caso, si el proceso que cierra el mutex lo tiene bloquedo, habra que desbloquearlo implícitamente.

• Por lo demas, la semántica asociada a el cierre es muy similar a la de un semáforo el mutex se eliminara realmente cuando no haya ningun descriptor asociado al mismo.

• Cuando un proceso temina ya sea voluntaria o involuntariamente el sistema operativo debe cerrar tanto los semáforos como los mutes que usaba el proceso.

PROBLEMÁTICA

En esta practica se tuvo mucho problemas ya que no se contaba con codigo y no se entendia bien el concepto de mutex que después se vio y es como un semáforo el cual tienen solo diferentes cararcteristicas pero funciona igual ademas ademas tienen mucha complicación los mutex para programadores no tan expertos es algo muy complicado ya que solo se entiende muy poco de su funcionamiento.

CONCLUSIONES:

En esta practica se logro el objetivo aplicar mutex junto con semáforos que ademas se sepan diferenciar y que tengan varias cosas en comun en este caso se tomo la version con hilos o theaters para modificar apartir de ahí se modifico el codigo y se obtuvo que fuero intercalando varios semaros con algunos mutes y en el momento que se cerraba ambos los terminaban los proceso y esa era la razon por la que los terminaro.