Informática de sistemas

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:
1
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.
2
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:
3
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
4
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.
5