PRÁCTICAS DE SISTEMAS OPERATIVOS II

PRIMERA PRÁCTICA EVALUABLE

Los filósofos maquineros

1. Enunciado.

   En un lejano país oriental la vida transcurre tranquila desde que terminó la guerra que dos potencias mundiales decidieron que se luchara allí para dilucidar sus diferencias y afán de dominio. Hay un templo perdido entre las montañas que sobrevivió milagrosamente al conflicto y un comedor donde se sirve esquisitos espagueti acompañados de una guarnición que varía con la época del año. Cruza nuestro escenario un río de aguas cristalinas, único obstáculo natural entre comedor y templo. El templo lo habitan varios filósofos, cuya vida transcurre plácida del modo siguiente¹:
   • Al despuntar el día, se dirigen al comedor y, para salvar el río, cruzan un puente.
   • El comedor dispone de una antesala donde solo caben cuatro filósofos a la vez. Los filósofos permanecen en la antesala hasta que ven un sitio libre en el comedor.
   • Una vez elegido el sitio, van hacia él, se sientan y deben coger dos tenedores situados a ambos lados del plato.
   • Comen hasta saciar mínimamente sus necesidades vitales pues saben que la frugalidad en el comer es sinónimo de una larga vida.
   • Dejan los tenedores, se levantan y vuelven al templo, debiendo cruzar en el otro sentido el mismo puente que cruzaron para llegar al comedor.
   • En el templo, se dedican a la meditación (o a dormir, que de todo hay) hasta que la naturaleza implacable les recuerda que deben reponer energías y volver a ir al comedor, con lo que el ciclo de su vida se repite.
   
   Fruto de la guerra, quedaron esparcidas por el terreno algunas bombas fallidas, por lo que los filósofos deben seguir siempre el mismo camino si no quieren verse expuestos al peligro de que una de ellas les explote. La única excepción al caso es una explanada situada en el camino entre el comedor y el puente, cerca de este último. Allí tienen más libertad de movimiento. La naturaleza es exuberante en el paraje, como consecuencia quizá de la fortuna de que no existan en las cercanías recursos naturales de interés económico. Probablemente por esta misma causa, las infraestructuras son escasas y mal conservadas. En concreto, el puente:
   • Es muy estrecho y alto, hecho de cuerdas y no permite que puedan circular personas en ambos sentidos a la vez.
   • Tampoco soporta mucho peso. Quiere decir que si se supera su máximo, se romperá.
   • Finalmente, en momentos de gran afluencia, puede ocurrir que siempre circulen filósofos en una dirección, por lo que se estableció la regla de que, siempre que haya personas esperando a cruzar en el otro sentido, solo un máximo de filósofos pueden cruzar en el sentido actual. Si se supera este máximo, los que quisieran entrar deben ceder el paso a los del otro sentido. Se indica mediante unos paneles en las entradas del puente cuántas personas pueden cruzar en esa dirección antes de tener que ceder el paso. Desafortunadamente, la humedad de la selva tropical no se lleva bien con la circuitería electrónica y, hay largas temporadas en las que el sistema de control simplemente no funciona². Se puede saber si los paneles no funcionan, porque en ese caso no aparecen los números verdes que indican cuántos filósofos aún pueden pasar en una dirección y el panel permanece negro. Si al arrancar la práctica este número no aparece, no tenéis que programar esta restricción.
   
   
   
   
   En esta práctica vamos a simular, mediante procesos de UNIX, el acontecer diario de los filósofos.
   
   El programa constará de un único fichero fuente, filosofar.c, cuya adecuada compilación producirá el ejecutable filosofar. Respetad las mayúsculas/minúsculas de los nombres.
   
   Para simplificar la realización de la práctica, se os proporciona una biblioteca estática de funciones (libfilosofar.a) que debéis enlazar con vuestro módulo objeto para generar el ejecutable. Gracias a ella, algunas de las funciones necesarias para realizar la práctica no las tendréis que programar sino que bastará nada más con incluir la biblioteca cuando compiléis el programa. La línea de compilación del programa podría ser:

   gcc filosofar.c libfilosofar.a -o filosofar -lm

   Disponéis, además, de un fichero de cabeceras, filosofar.h, donde se encuentran definidas, entre otras cosas, las macros que usa la biblioteca.
   
   Cada filósofo vendrá representado por un proceso, siendo todos ellos hijos del mismo proceso padre resultado de arrancar el programa. El programa recibe tres argumentos: el número de filósofos que se debe crear (comprendido entre 1 y el valor de la macro MAXFILOSOFOS de filosofar.h), el número de vueltas que debe dar cada filósofo antes de morir y la lentitud de ejecución, un número mayor o igual que cero. Este último valor se ha de pasar a la biblioteca para que ella gestione la velocidad de la simulación.
   
   Los parámetros concretos de la simulación, como pueden ser el número de sitios de comedor y templo, capacidad máxima del puente, etc., son informados por la propia biblioteca al arrancar. Para la resolución de la práctica se pueden usar un único conjunto de semáforos, una única zona de memoria compartida y un único buzón. Mientras los dos primeros se necesitan crear aunque no se usen, pues los necesita la biblioteca, el tercero es opcional. El proceso padre debe realizar las siguientes acciones:
   • Comprobar los argumentos pasados e indicar la forma de uso si son incorrectos.
   • Registrar las señales que se vayan a usar.
   • Obtener los recursos IPC:
     • Semáforos: la biblioteca informa mediante la función FI_getNSemAforos acerca de cuántos semáforos necesita para su funcionamiento interno. Se reservarán los primeros semáforos del conjunto para la bibloteca, pudiendo el programador solicitar y usar más para realizar la correcta sincronización.
     • Memoria compartida: de nuevo, mediante la función FI_getTamaNoMemoriaCompartida, la biblioteca declara cuánta memoria necesita para su uso. Se puede reservar una cantidad mayor, pero se debe dejar los primeros bytes para uso exclusivo de la biblioteca.
     • Buzón: la biblioteca no usa buzones para su funcionamiento, por lo que queda a la decisión del programador solicitarlo o no.
   • Invocar la función de la biblioteca FI_inicio. Se debe usar la clave: 41211294392005.
   • Crear tantos procesos como se haya indicado en la línea de órdenes. El funcionamiento de cada proceso filósofo se indica a continuación.
   • Esperar por la muerte de los procesos hijos sin consumir CPU.
   • Eliminar los recursos IPC.
   • Llamar a la función FI_fin.
   • Estos tres últimos puntos los debe realizar tanto en una terminación normal, como en una terminación anormal debido a la pulsación de CTRL+C o a un error.
   
   Por su parte, los procesos filósofos deben:
   • Llamar a la función FI_inicioFilOsofo. Cada proceso debe llamar a la función con un identificador diferente (un número entre 0 y el número de filósofos menos 1), aunque no es necesario que los filósofos llamen a esta función en orden.
   • Efectuar tantas vueltas como lo indicado en la línea de órdenes. En cada vuelta, deben:
     • Andar mientras la siguiente zona sea CAMPO.
     • Quedarse bloqueado sin consumo de CPU hasta que se den las condiciones para cruzar el puente hacia la izquierda.
     • Andar mientras la siguiente zona sea PUENTE.
     • Dar un paso y, en este punto seguro que se necesita avisar al resto de que se ha abandonado el puente.
     • Andar mientras la siguiente zona no sea ANTESALA.
     • Quedarse bloqueado si la antesala está llena.
     • Andar mientras la siguiente zona sea ANTESALA.
     • Quedarse bloqueado mientras no haya sitio en el comedor.
     • Llamar a la función FI_entrarAlComedor, indicando el sitio libre escogido.
     • Andar mientras la siguiente zona sea ENTRADACOMEDOR.
     • Coger ambos tenedores, según el algoritmo usado, llamando a las funciones FI_cogerTenedor dos veces. Solo se puede llamar a estas funciones cuando el tenedor a que se refieran esté libre.
     • Llamar a la función FI_comer mientras devuelva SILLACOMEDOR.
     • Dejar ambos tenedores llamando a la función FI_dejarTenedor por cada uno de ellos.
     • Dar un paso y posiblemente indicar al resto de procesos que ese sitio está ya libre.
     • Andar mientras la siguiente zona no sea PUENTE.
     • Repetir las acciones realizadas anteriormente, solo que ahora para cruzar el puente hacia la derecha.
     • Una vez cruzado el puente, andar mientras la siguiente zona no sea TEMPLO.
     • Bloquearse mientras no haya al menos un sitio libre en el templo.
     • Elegir un sitio libre y llamar a la función FI_entrarAlTemplo señalando el sitio elegido.
     • Andar mientras la siguiente zona sea TEMPLO.
     • Llamar a la función FI_meditar mientras esta devuelva SITIOTEMPLO.
   • Llamar a la función FI_finFilOsofo.
   
   Una parte complicada del programa es que los filósofos anden, pues deben evitar chocarse con otro filósofo. El proceso consta de tres partes:
   1. Llamar a la función FI_pausaAndar. Esta llamada se debe hacer fuera de cualquier sección crítica u observaremos un enlentecimiento artificial de la práctica a baja velocidad que aumenta con el número de procesos, llegando incluso a bloquearse intermitentemente.
   2. Llamar a la función FI_puedoAndar. Esta función devuelve el valor 100 si la vía está libre. Si no lo está, devuelve el identificador del filósofo que está bloqueando nuestro camino.
   3. Si hay vía libre, llamar a la función FI_andar.
   Aparte de la incuestionable sincronización que debe existir en este proceso, se ofrece al programador dos posibilidades en el caso de que la función nos indique que el camino está bloqueado:
   • Hacer semiespera ocupada: hacer una pausa de 50 milisegundos y volver a intentarlo. Esta solución opta a peor calificación.
   • Quedarse bloqueado sin consumo de CPU esperando a que el proceso responsable de la obstrucción nos indique que podemos continuar con, por ejemplo un semáforo por proceso o mediante mensajes de un buzón. Esta solución opta a la máxima nota.
   
   

   Características adicionales que programar

   • El programa no debe consumir CPU apreciablemente en los modos de lentitud mayor o igual que 1. Para comprobar el consumo de CPU, podéis usar la orden top.
   • IMPORTANTE: Aunque no se indique explícitamente en el enunciado, parece obvio que se necesitarán objetos de sincronización en diferentes partes del programa.
   • Se permite hacer semiespera ocupada cuando un filósofo vea bloqueado su camino, pero de hacerse así, la nota se verá rebajada.
   
   
   El programa debe estar preparado para que, si el usuario pulsa las teclas CTRL-C desde el terminal, la ejecución del programa termine en ese momento y adecuadamente. Ni en una terminación como esta, ni en una normal, deben quedar procesos en ejecución ni mecanismos IPC sin haber sido borrados del sistema. Este es un aspecto muy importante y se penalizará bastante si la práctica no lo cumple.
   
   Las funciones proporcionadas por la biblioteca libfilosofar.a son las que a continuación aparecen. De no indicarse nada, las funciones devuelven -1 en caso de error:
   • int FI_inicio(int ret, unsigned long long clave, struct DatosSimulaciOn *ddssp, int semAforos, int memoCompartida, int const *dE)
     El proceso padre debe llamar a esta función cuando desee que la simulación comience. Los argumentos son:
     1. ret: lentitud de ejecución. Es el valor que se ha pasado como primer argumento al programa.
     2. clave: en esta clave van codificados los datos concretos de la simulación. Más arriba se especificó cuál es el valor que se debe introducir.
     3. ddssp: se debe pasar por aquí una variable de tipo struct DatosSimulaciOn donde la función devuelve los datos concretos asociados a la clave introducida. La definición de struct DatosSimulaciOn se encuentra en filosofar.h.
     4. semAforos: identificador del array de semáforos devuelto por semget.
     5. zona: idem para la zona de memoria compartida (no es el puntero, sino lo que devuelve shmget).
     6. dE: puede ser NULL, en cuyo caso no se desea que la biblioteca produzca información de depuración por el canal de errores estándar. Si se pasa un array, los filósofos indicarán en qué dirección se desplazan y, adicionalmente, cada elemento del array señala si se desea información o no de cada uno de los subestados por los que pasa un filósofo:
        -1. Información completa, incluyendo los pasos que dan los filósofos.
        0. No se desea información de este subestado.
        1. Se desea información, pero se pide omitir la información de cada paso.
        Se puede tomar como referencia esta plantilla con el nombre de los subestados:

          // Sustituir por 1, si se desea depurar sin detallar cada avance del
          //                  filOsofo o con
          //              -1, si no se desea depurar pero sin este detalle 
          int dE[]={0, // Cigoto,
                    0, // PasilloSalidaTemplo,
                    0, // CaminoTemploPuente,
                    0, // PuenteHaciaComedor,
                    0, // CaminoPuenteComedor,
                    0, // PasilloEntradaComedor,
                    0, // Antesala,
                    0, // EntradaComedor,
                    0, // SillaComedor,
                    0, // SalidaComedor,
                    0, // PasilloSalidaComedor,
                    0, // ExplanadaComedorPuente,
                    0, // PuenteHaciaTemplo,
                    0, // CaminoPuenteTemplo,
                    0, // PasilloEntradaTemplo,
                    0, // EntradaTemplo,
                    0, // SitioTemplo,
                    0, // SalidaTemplo,
                    0  // Fin
                    };
        

   • int FI_inicioFilOsofo(int nFilOsofo)
     Cada proceso invoca esta función al inicio. Se pasa el identificador del nuevo filósofo (un número entero mayor o igual que cero y menor que el número de filósofos menos uno). El identificador debe ser diferente para cada proceso aunque no es necesario que los procesos invoquen de modo sucesivo la función.
   • int FI_pausaAndar(void)
     Antes de dar cualquier paso, el filósofo debe invocar esta función. Debe invocarla una vez y solo una vez antes de dar un paso. Esta función, al realizar una pausa, no se debe llamar con cualquier sección crítica tomada.
   • int FI_puedoAndar(void)
     Para saber si el lugar al que quiere avanzar el filósofo está libre, debe invocar esta función, que devuelve el valor 100 si es seguro andar o el identificador del filósofo que nos impide el paso. Nótese que, si no se toman medidas, puede ocurrir que entre que se llama a esta función y se llama a la siguiente, la situación puede haber cambiado.
   • int FI_andar(void)
     Avanza un paso hacia el destino del filósofo. Si, al avanzar, se tropieza con otro, da error. Si el avance es fructuoso, devuelve la zona a la que avanzará en el siguiente paso. Los códigos de las zonas se encuentran en el fichero filosofar.h
   • int FI_entrarAlComedor(int puesto)
     Antes de pasar al comedor, los filósofos al final de la antesala, deben elegir un puesto libre del comedor e invocar esta función.
   • int FI_cogerTenedor(int t)
     Con esta función los filósofos indican que cogen un tenedor, que debe estar libre en esos momentos. El argumento puede ser TENEDORDERECHO o TENEDORIZQUIERDO, macros definidas en filosofar.h.
   • int FI_comer(void)
     Una vez el filósofo está en posesión de ambos tenedores, debe llamar sucesivamente a esta función hasta que devuelva distinto de SILLACOMEDOR, macro de filosofar.h.
   • int FI_dejarTenedor(int t)
     Función complementaria de FI_cogerTenedor y con el mismo parámetro. Se invoca para dejar cada tenedor, una vez el filósofo ha comido.
   • int FI_entrarAlTemplo(int puesto)
     Antes de entrar al templo, el filósofo debe asegurarse de que hay un puesto libre para meditar y pasarle el identificador de dicho puesto a la biblioteca mediante esta función.
   • int FI_meditar(void)
     Una vez en el puesto de meditación, el filósofo invoca sucesivamente esta función hasta que devuelva un valor distinto de SITIOTEMPLO, macro de filosofar.h.
   • int FI_finFilOsofo(void)
     Es llamada por los procesos de los filósofos, una vez han dado las vueltas correspondientes, antes de morir.
   • int FI_fin(void)
     La llama el proceso padre para acabar la simulación después de esperar por la muerte de los hijos y haber destruido los mecanismos IPC usados.
   • int FI_getTamaNoMemoriaCompartida()
int FI_getNSemAforos()
     Estas funciones devuelven los requerimientos de la biblioteca respecto a la memoria compartida (bytes) o número de semáforos
   • void pon_error(char *mensaje)
     Pone un mensaje de error en la parte inferior de la pantalla y espera a que el usuario pulse "Intro". La podéis usar para depurar.
   
   
   Estad atentos pues pueden ir saliendo versiones nuevas de la biblioteca para corregir errores o dotarla de nuevas funciones.
   
   Respecto a la sincronización interna de la biblioteca, se usa un semáforo reservado para conseguir atomicidad en la actualización de la pantalla (semPantalla, iniciado a 1) y otro semáforo para hacer lo propio con los estados de la simulación (semTotal, iniciado también a 1).
   
   En esta práctica no se podrán usar ficheros para nada, salvo que se indique expresamente. Las comunicaciones de PIDs o similares entre procesos, si hicieran falta, se harán mediante mecanismos IPC.
   
   Siempre que en el enunciado o LPEs se diga que se puede usar sleep(), se refiere a la llamada al sistema, no a la orden de la línea de órdenes.
   
   Los mecanismos IPC (semáforos, memoria compartida y paso de mensajes) son recursos muy limitados. Es por ello, que vuestra práctica solo podrá usar un conjunto de semáforos, un buzón de paso de mensajes y una zona de memoria compartida como máximo. Además, si se produce cualquier error o se finaliza normalmente, los recursos creados han de ser eliminados. Una manera fácil de lograrlo es registrar la señal SIGINT para que lo haga y mandársela uno mismo si se produce un error.
   
   

   Biblioteca de funciones libfilosofar.a

   Con esta práctica se trata de que aprendáis a sincronizar y comunicar procesos en UNIX entre sí. Su objetivo no es la programación, aunque es inevitable que tengáis que programar. Es por ello que se os suministra una biblioteca estática de funciones ya programadas para tratar de que no debáis preocuparos por la presentación por pantalla, la gestión de estructuras de datos (colas, pilas, ...) , etc. También servirá para que se detecten de un modo automático errores que se produzcan en vuestro código. Para que vuestro programa funcione, necesitáis la propia biblioteca libfilosofar.a y el fichero de cabecera filosofar.h. La biblioteca funciona con los códigos de VT100/xterm, por lo que debéis adecuar la emulación de vuestro terminal.

   Ficheros necesarios:

   • libfilosofar.a: para Solaris (ver 2.0), para el LINUX de clase (ver 2.0),
   • filosofar.h: Para todos (ver 1.2).
   
   

2. Pasos recomendados para la realización de la práctica

   Aunque ya deberíais ser capaces de abordar la práctica sin ayuda, aquí van unas guías generales:
   1. Hacer el código necesario para gestionar los argumentos que se le pasan al programa
   2. Crear los semáforos, la memoria comparida y el buzón (si es que vais a usar uno), y comprobad que se crean bien con ipcs. Es preferible, para que no haya interferencias, que los defináis privados.
   3. Registrar SIGINT para que cuando se pulse CTRL-C se eliminen los recursos IPC. Lograr que si el programa acaba normalmente o se produce cualquier error, también se eliminen los recursos (mandad una señal SIGINT en esos casos al proceso padre).
   4. Llamar a la función FI_inicio en main. Debe aparecer la pantalla de bienvenida y, pasados dos segundos, dibujarse la pantalla. Para la clave, usad el número proporcionado más arriba. Recoged los datos de simulación y mostradlos por el canal de errores. Incluid la plantilla del array de depuración y pasádselo a la función. Ejecutad la práctica, a partir de ahora, redirigiendo la salida de errores a un fichero para que no se os emborrone la pantalla.
   5. Los siguientes pasos conllevan resolver la práctica, según los parámetros que habéis recibido en los datos de la simulación.
   6. Que el padre cree ahora un proceso hijo y se quede esperando por su muerte. Este proceso no debe hacer, de momento, nada.
   7. Podéis ya dar vida a este proceso. Probad a que dé varios pasos. No será necesario que toméis precauciones si no puede avanzar, porque al estar solo, siempre podrá.
   8. Meted las órdenes para dar un paso en un bucle y considerad lo que devuelve FI_andar para ir resolviendo el ciclo de vida del filósofo. Como el filósofo está solo, no hace falta que os preocupéis por los condicionantes del puente, podéis elegir siempre el puesto 0 en el comedor y el templo, etc.
   9. Controlad que el filósofo dé las vueltas que pide en el enunciado y acabe sin dar problemas.
   10. Llega el momento crucial: cread dos filósofos. Si el segundo corre más que el primero, se tropezará con él, dando error. Resolved el problema según lo que hayáis decidido (semiespera ocupada o bloqueo del que espera).
   11. Id añadiendo sucesivamente más filósofos y resolviendo, uno a uno, los condicionantes del problema: que no entren en una antesala llena, que esperen a que haya un sitio en comedor o templo, que no pasen al puente si viene alguien en la otra dirección, etc.
   12. Una vez penséis que están resueltos todos los problemas, probad la simulación a lentitud 0. Si aparecen nuevos problemas, solucionadlos. Si no, haced vuestro esquema de sincronización y analizadlo desde el punto de vista teórico.
   13. Pulid los últimos detalles.
   14. Llevar la práctica al servidor y, en caso de detectarse errores, corregidlos.
   
   
   

3. Plazo de presentación.

   Consultad la página de entrada de la asignatura.
   
   

4. Normas de presentación.

   Acá están. Además de estas normas, en esta práctica se debe entregar un esquema donde aparezcan los semáforos usados, sus valores iniciales, los buzones, y mesajes pasados y un seudocódigo sencillo para cada proceso con las operaciones wait y signal, send y receive realizadas sobre ellos. Por ejemplo, si se tratara de sincronizar dos procesos C y V para que produjeran alternativamente consonantes y vocales, comenzando por una consonante, deberíais entregar algo parecido a esto:

        SEMÁFOROS Y VALOR INICIAL: SC=1, SV=0.
   
        SEUDOCÓDIGO:
   
                C                                V
               ===                              ===
          Por_siempre_jamás               Por _siempre_jamás
             {                               {
              W(SC)                           W(SV)
              escribir_consonante             escribir_vocal
              S(SV)                           S(SC)
              }                               }
   

   Daos cuenta de que lo que importa en el pseudocódigo es la sincronización. El resto puede ir muy esquemático. Un buen esquema os facilitará muchísimo la defensa.
   
   

5. Evaluación de la práctica.

   Dada la dificultad para la corrección de programación en paralelo, el criterio que se seguirá para la evaluación de la práctica será: si
   1. la práctica cumple las especificaciones de este enunciado y,
   2. la práctica no falla en ninguna de las ejecuciones a las que se somete y,
   3. no se descubre en la práctica ningún fallo de construcción que pudiera hacerla fallar, por muy remota que sea esa posibilidad...
   se aplicará el principio de "presunción de inocencia" y la práctica estará aprobada. La nota, a partir de ahí, dependerá de la simplicidad de las técnicas de sincronización usadas, la corrección en el tratamiento de errores, la cantidad y calidad del trabajo realizado, si se ha optado por semiespera ocupada, etc.
   
   

6. LPEs.

   1. ¿Se puede usar la biblioteca en un Linux de 32 bits? No. Esta práctica está compilada para 64 bits.
   2. ¿Se puede proporcionar la biblioteca para el Sistema Operativo X, procesador Y? Por problemas de eficiencia en la gestión y mantenimiento del código no se proporcionará la biblioteca más que para Solaris-SPARC y Linux de 64 bits (con procesador de Intel o AMD). A veces podéis lograr encontrar una solución mediante el uso de máquinas virtuales.
   3. ¿Dónde poner un semáforo? Dondequiera que uséis la frase, "el proceso puede llegar a esperar hasta que..." es un buen candidato a que aparezca una operación wait sobre un semáforo. Tenéis que plantearos a continuación qué proceso hará signal sobre ese presunto semáforo, dónde lo hará y cuál será su valor inicial.
   4. Si ejecutáis la práctica en segundo plano (con ampersand (&)) es normal que al pulsar CTRL+C el programa no reaccione. El terminal sólo manda SIGINT a los procesos que estén en primer plano. Para probarlo, mandad el proceso a primer plano con fg % y pulsad entonces CTRL+C.
   5. Un "truco" para que sea menos penoso el tratamiento de errores consiste en dar valor inicial a los identificadores de los recursos IPC igual a -1. Por ejemplo, int semAforo=-1. En la manejadora de SIGINT, sólo si semAforo vale distinto de -1, elimináis el recurso con semctl. Esto es lógico: si vale -1 es porque no se ha creado todavía o porque al intentar crearlo la llamada al sistema devolvió error. En ambos casos, no hay que eliminar el recurso.
   6. Para evitar que todos los identificadores de recursos tengan que ser variables globales para que los vea la manejadora de SIGINT, podéis declarar una estructura que los contenga a todos y así sólo gastáis un identificador del espacio de nombres globales.
   7. A muchos os da el error "Interrupted System Call". Mirad la sesión dedicada a las señales, apartado quinto. Allí se explica lo que pasa con wait. A vosotros os pasa con semop, pero es lo mismo. De las dos soluciones que propone el apartado, debéis usar la segunda.
   8. A muchos, la práctica os funciona exasperantemente lenta en encina. Debéis considerar que la máquina cuando la probáis está cargada, por lo que debe ir más lento que en casa o en el linux de clase.
   9. A aquellos que os dé "Bus error (Core dumped)" al dar valor inicial al semáforo, considerad que hay que usar la versión de semctl de Solaris (con union semun), como se explica en la sesión de semáforos.
   10. Al acabar la práctica, con CTRL+C, al ir a borrar los recursos IPC, puede ser que os ponga "Invalid argument", pero, sin embargo, se borren bien. La razón de esto es que habéis registrado la manejadora de SIGINT para todos los procesos. Al pulsar CTRL+C, la señal la reciben todos, el padre y los otros procesos. El primero que obtiene la CPU salta a su manejadora y borra los recursos. Cuando saltan los demás, intentan borrarlos, pero como ya están borrados, os da el error.
   11. El compilador de encina tiene un bug. El error típicamente os va a ocurrir cuando defináis una variable entera en memoria compartida. Os va a dar Bus Error. Core dumped si no definís el puntero a esa variable apuntando a una dirección que sea múltiplo de cuatro. El puntero que os devuelve shmat, no obstante, siempre será una dirección múltiplo de cuatro, por lo que solo os tenéis que preocupar con que la dirección sea múltiplo de cuatro respecto al origen de la memoria compartida. La razón se escapa un poco al nivel de este curso y tiene que ver con el alineamiento de direcciones de memoria en las instrucciones de acceso de palabras en el procesador RISC de encina.
   12. Todos vosotros, tarde o temprano, os encontráis con un error que no tiene explicación: un proceso que desaparece, un semáforo que parece no funcionar, etc. La actitud en este caso no es tratar de justificar la imposibilidad del error. Así no lo encontraréis. Tenéis que ser muy sistemáticos. Hay un árbol entero de posibilidades de error y no tenéis que descartar ninguna de antemano, sino ir podando ese árbol. Tenéis que encontrar a los procesos responsables y tratar de localizar la línea donde se produce el error. Si el error es "Segmentation fault. Core dumped", la línea os la dará si aplicáis lo que aparece en la sección Manejo del depurador. En cualquier otro caso, no os quedará más remedio que depurar mediante órdenes de impresión dentro del código.
       
       Para ello, insertad líneas del tipo:

                            fprintf(stderr,"%d:...",getpid(),...);

       donde sospechéis que hay problemas. En esas líneas identificad siempre al proceso que imprime el mensaje. Comprobad todas las hipótesis, hasta las más evidentes. Cuando ejecutéis la práctica, redirigid el canal de errores a un fichero con 2>salida.
       
       Si cada proceso pone un identificador de tipo "P1", "P2", etc. en sus mensajes, podéis quedaros con las líneas que contienen esos caracteres con:

                            grep "P1" salida > salida2