Hola a todos, bienvenidos a esta nueva videotutoria Intercampus de la
asignatura Ampliación de Sistemas Operativos. En esta clase vamos a
continuar en el punto en el que lo habíamos dejado en la clase anterior,
que si recordáis estábamos viendo el tema 3 y nos habíamos quedado en
las llamadas al sistema que están asociadas con las colas de mensajes de
los mecanismos IPC del System 5. Para hacer un repaso general de la última
parte que vimos, para situaros un poco, estábamos en la tercera parte del
tema que comenzaba en la página 118 y que se titulaba Mecanismos de
Comunicación entre Procesos Soft Units. Esa última parte... iba a
explicar más detalladamente los mecanismos IPC del System 5. Habíamos
visto que serían tres los tipos de mecanismos IPC que utiliza el System 5.
Por un lado eran los semáforos, luego teníamos las colas de mensajes y
por último estaría la memoria compartida. Los semáforos ya lo habíamos
visto, os había emplazado a que vieseis los diferentes ejemplos que os
viene en el libro y ahora estábamos inmersos en el segundo concepto que
era, o segundo mecanismo, las colas de mensajes. Las habíamos descrito, su
descripción venía en la página 124 del libro de texto y ahora íbamos a
pasar a ver las llamadas al sistema que están asociadas a ese mecanismo
que son las colas de mensajes. En el libro de texto podéis situaros ahora
en la página 125 y yo aquí voy a avanzar mis diapositivas para empezar a
explicaros la primera llamada al sistema que se utiliza en este tipo de
mecanismos. La primera llamada al sistema que vamos a ver sería la que
tenéis aquí, MSGJET y entre paréntesis la introducción de los
argumentos que en este caso serían solamente dos y uno se llamaría llave
y otro se llamaría IN. ¿Qué hace esta llamada al sistema? Pues esta
llamada permite crear una cola de mensajes nueva o obtener el acceso a una
cola de mensajes que ya haya sido creada. Esa sería la función principal
de esa llamada al sistema. Requiere, como decíamos, dos argumentos. Uno
sería el argumento llave que se va a asignar a la nueva cola o la llave de
la cola que ya ha sido creada y luego también vamos a introducir como
argumentos una serie de indicadores que le llamamos IN que permitirán
especificar, entre otras cosas, los permisos de acceso a la cola. ¿De
acuerdo? Entonces, que tengáis muy presente las funciones o más bien las
tareas que realiza la llamada al sistema MSGJET. Luego, la siguiente
llamada al sistema que vamos a ver la tenéis aquí. Se denomina MSGJET.
SND y entre paréntesis ahora vamos a tener en lugar de dos argumentos,
como el caso anterior vamos a aumentar esos argumentos. Ahora vamos a pasar
de dos a cuatro. ¿Vale? Los tenéis aquí. Por un lado tenemos el MSGGIF
que ya suponéis que es el identificador de grupo de ese mensaje. Otro
argumento que se denomina MEN otro argumento que se denomina TAM y otro
argumento que se denomina IN. ¿De acuerdo? ¿Qué es lo que hace esta
llamada al sistema? Pues permitirá enviar un mensaje a una determinada
cola. ¿De acuerdo? Bien. Esa es la función de esa llamada al sistema.
Pero ahora cada uno de los argumentos sirve para lo siguiente. El argumento
MSGJET ¿Vale? Lo tendremos que introducir. Luego también introduciremos
bueno, como os decía, el argumento MSGJET. Como os decía, ese argumento
sería el identificador de la cola de mensajes. ¿Vale? Luego también
vamos a introducir un puntero que denominamos MEN que será un puntero al
buffer que contiene el mensaje que se desea enviar. ¿Vale? Luego
tendríamos que introducir el tamaño. El tamaño le llamamos TAM y sería
el tamaño en bytes de ese mensaje que deseamos enviar. Por último
necesitaríamos introducir un argumento que llamaríamos IN que permitiría
especificar el comportamiento de esa llamada al sistema. Bien, pues esa
sería básicamente esa llamada al sistema. Seguimos en la página 125 del
libro y ahora vemos otra llamada al sistema que se denomina en este caso
MSGRCV ¿Vale? Y como argumentos tendremos 1, 2, 3, 4 y 5. Seguimos
aumentando la lista de argumentos. En este caso pasaríamos de 4 que
veíamos en la llamada anterior a 5 que tendríamos en esta nueva llamada.
¿Qué permitirá hacer esta llamada al sistema? Pues permite recibir un
mensaje de una determinada cola. La anterior permitía enviarlo y esta
última permite recibirlo. ¿Qué argumentos vamos a necesitar en esta
nueva llamada al sistema? Pues necesitaríamos de nuevo el identificador de
la cola de mensajes que denominamos como en el caso anterior MSGID ¿Vale?
Luego también necesitaríamos un puntero que denominamos main que iría o
apuntaría mejor dicho al bufe donde se almacenará el mensaje que se desea
recibir ¿Vale? Y luego tendríamos el número máximo de bytes que serán
almacenados del mensaje. ¿De acuerdo? Este número máximo de bytes lo
denominaremos max. También deberemos introducir el tipo de mensaje El tipo
de mensaje lo vamos a denominar tipo main y por último tendríamos que
introducir un indicador que denominaremos int que permitirá especificar el
comportamiento de la llamada. ¿De acuerdo? Todas estas características de
cada llamada debemos tenerlas muy en cuenta para poder aplicarlas con
éxito. También tenéis en esas páginas 125 y 126 más información
detallada ¿De acuerdo? Yo aquí os he puesto lo principal y lo más
importante a tener en cuenta Ahora vamos a ver otra llamada del sistema que
se denomina en este caso MSGCTL Y aquí reducimos el número de argumentos
a 3 ¿De acuerdo? Primero estaría msghit luego orden y luego alt ¿Qué
hace esta llamada al sistema? Pues esta llamada permite leer y configurar
los datos de control que el núcleo mantiene en la entrada asociada a una
determinada cola de mensajes en las tablas de cola de mensajes ¿De
acuerdo? Requerirá que introduzcamos como argumentos un identificador de
la cola de mensajes que volvemos a denominar msgib un número entero o
constante simbólica que vamos a llamar orden y que especificará la
operación que se quiere realizar sobre los datos de administración y
control de la cola Y por último tendríamos que introducir los argumentos
que son asociados a dicha operación Los argumentos que asociaremos a esa
operación les llamaremos ar Vamos a ver que valores pueden tomar ese
argumento orden que veíamos aquí Ese argumento va a poder tomar los
siguientes valores Por un lado estaría el valor ipcrnib que veis aquí que
especifica que el recurso ipc debe ser eliminado ¿De acuerdo? Además de
que especifique que deberá ser eliminado Deberá despertar a todos los
procesos dormidos esperando por una operación de envío o recepción en la
cola de mensajes Como veis ahí despertará a todos los procesos que estén
dormidos y que estén esperando por una operación de envío o de
recepción en la cola de mensajes Otro valor posible para el argumento
orden sería ipcstat lo que hace es leer el contenido de la estructura de
datos que esté asociada al recurso ipc y almacenarlo en la estructura
apuntada en ar Luego también podría tomar el valor ipcset que lo que hace
es configurar asociada al recurso ipc con los valores que estén
almacenados en la estructura apuntada en ar ¿Vale? Si esta llamada al
sistema se ejecutara con éxito devolverá el valor cero ¿De acuerdo? Y en
caso contrario que haya algún error devolverá el valor menos uno Bien,
pues hasta aquí sería el mecanismo de cola de mensajes Ya hemos visto el
de semáforos y el de cola de mensajes Os quedaría por ver el tercer
mecanismo que utiliza el System 5 que es el mecanismo de memoria compartida
este que veis aquí que en el libro lo tenéis en la página 128 Podéis
ver o leer por vuestra cuenta también el ejemplo 3.11 para que entendáis
un poco el uso de las colas de mensajes ¿De acuerdo? Ese ejemplo 3.11
viene mejor explicado os aporta varios códigos que podéis ver en las
figuras 3.12 y 3.13 de la página 127 y la figura 3.14 de la página 128
¿Vale? Si echáis un vistazo y con eso intentáis entender mejor los
contenidos teóricos que hemos visto en esta tutorial Ahora vamos a pasar a
ver como decía, la memoria compartida En determinadas aplicaciones
interesa que diferentes procesos tengan acceso a una misma región de
memoria compartida De esa manera los cambios que haga un proceso sobre los
datos almacenados en esa región de memoria son visibles al resto de
procesos Esta funcionalidad que os he explicado es la que proporciona el
mecanismo IPC del System 5 que estamos estudiando y se conoce como memoria
compartida De ahí el nombre que da título a este apartado La memoria
compartida sería una región de memoria que puede ser leída o escrita por
varios procesos Esa sería la definición Para operar sobre una región de
memoria compartida lo que hace un proceso en primer lugar es crear la
memoria, obtener un proceso a la misma y a continuación adjuntarla a su
espacio de direcciones virtuales ¿De acuerdo? Decir también que si un
proceso debe acceder más a una región de memoria compartida debe
eliminarla de su espacio de direcciones virtuales Esto es muy importante
que lo haga en primer lugar El núcleo soporta las siguientes llamadas al
sistema asociadas con las regiones de memoria compartida Es decir, ahora
vamos a hacer lo mismo que en el caso anterior con las colas de mensajes
Vamos a describir qué llamadas al sistema aparecen asociadas a las
regiones de memoria compartida Esto lo veis en la página 129 del libro En
primer lugar vamos a ver la llamada al sistema SHMJ Entre paréntesis
introducimos el argumento llave, tamaño e id Esta llamada al sistema lo
que hace es crear una nueva región de memoria compartida o obtener acceso
a una región de memoria compartida que haya sido creada con anterioridad
Es decir, que ya exista Debemos introducir tres argumentos en esta llamada
al sistema Un argumento que era el argumento llave que es el que se va a
asignar a una nueva región o la llave de la región que ya ha sido creada
Luego, por otro lado estaría el argumento tamaño que sería el tamaño en
bytes de la región Y por último deberíamos introducir una serie de
indicadores que vamos a llamar IN que permitirán especificar los permisos
de acceso a la región Entre las cosas que permite especificar estarían
los permisos de acceso a la región compartida Luego tendríamos la llamada
al sistema SHMAT Y entre paréntesis introduciríamos los argumentos SHMID
DIR y el argumento IN Es decir, otros tres argumentos Esta llamada al
sistema lo que hace es adjuntar una región de memoria compartida en el
espacio de direcciones virtuales del proceso invocante ¿De acuerdo?
Deberíamos introducir varios argumentos como decía en este caso en
concreto serían tres Uno de ellos sería el identificador de la región de
memoria compartida que le vamos a llamar SHMID Luego deberíamos introducir
también la dirección virtual del espacio del proceso DIR a partir de la
cual se desearía que la región de memoria compartida fuese adjuntada Y
por último una serie de indicadores que permitirán establecer el modo de
acceso del proceso a la región de memoria Estos indicadores como siempre
les vamos a llamar IN Pasamos a ver otra llamada al sistema En este caso se
denomina SHMDT Y aquí vamos a tener un solo argumento de entrada Esta
llamada al sistema lo que hace es desajuntar una región de memoria
compartida del espacio de direcciones virtuales de un proceso Eso sería la
definición de esa llamada al sistema que la podéis ver en la página 130
del libro del texto y requiere como decía un único parámetro de entrada
que es la dirección virtual de inicio de la región de memoria compartida
que es lo que se denomina DIRV0 ¿De acuerdo? Si esta llamada al sistema se
ejecuta correctamente devolverá el valor 0 ¿Vale? Si por el contrario se
produce algún tipo de error esta llamada al sistema devolverá el valor
menos 1 Entonces esta seguiría siendo la manera habitual de proceder de
este tipo de llamadas al sistema Por último otra llamada al sistema que se
puede utilizar en la memoria compartida sería la que se denomina SHMCPL y
a ella le podemos añadir tres argumentos Un argumento sería SHMID como el
caso anterior otro argumento sería ORDE y otro argumento sería AR ¿De
acuerdo? ¿Qué es lo que permite este sistema? Pues permitirá leer y
configurar los datos de control que el núcleo mantiene sobre una región
de memoria compartida y la sintaxis de esta llamada al sistema sería muy
similar a la que hemos visto en las llamadas anteriores SHMCPL y MSF GCPL
Estas dos que teníamos aquí Luego tenéis en la página 130 un ejemplo
que podéis leer para como siempre entender mejor estos conceptos teóricos
que vemos en clase y este ejemplo se alargaría en la página 131 y
acabaría en la página 132 ¿De acuerdo? Entonces esas figuras que vienen
incorporadas en el ejemplo Figura 315 y figura 316 podéis echarles un
vistazo para entender como digo mejor todo este contenido teórico Ahora
vamos a ver una serie de ventajas e inconvenientes de estos mecanismos IPC
del System 5 Estos mecanismos IPC que hemos visto a lo largo de esta
videotutoria y de la anterior poseen una gran versatilidad ya que pueden
utilizarse para diferentes cosas Son las cosas que vamos a describir a
continuación Por un lado los semáforos se pueden utilizar para garantizar
la exclusión mutua en el uso de un recurso crítico o para sincronización
de procesos Esa sería la principal función de los semáforos Pero los
semáforos también introducen un inconveniente que sería el inconveniente
principal y es que si no se colocan adecuadamente en el código de la
aplicación o se realiza una operación incorrecta puede producir
condiciones de carrera e interbloqueo ¿De acuerdo? Ese sería el
inconveniente que nos aportarían los semáforos En las aplicaciones que
cuenten con un código largo y con decenas de semáforos estas
equivocaciones serían fácilmente producibles Entonces que lo tengáis en
cuenta Si es una aplicación con un código pequeñito o que utilice pocos
semáforos pues sería más difícil incurrir en este tipo de
equivocaciones Pero como os pone en el libro si se trata de un programa
largo o que el programador utilice muchos semáforos es fácil que caigamos
en una equivocación de este tipo Las colas de mensajes se pueden utilizar
para las mismas funciones que acabamos de decir para los semáforos y
además para el intercambio de pequeñas cantidades de datos Esto es muy
importante porque heredan de los mecanismos anteriores que son los
semáforos ese tipo de funciones y además añaden el intercambio de
pequeñas cantidades de datos El inconveniente que introducen las colas de
mensajes sería que la transferencia de un mensaje requiere de dos copias
en memoria Y esto lógicamente ralentiza la operación Ese sería el
principal inconveniente que aportarían las colas de mensajes Como os he
puesto aquí que os indica el libro el mensaje En primer lugar el mensaje
es enviado por un proceso emisor Se enviaría una cola de mensajes y es
copiado desde el espacio de direcciones del proceso en un buffer del
núcleo Luego a continuación cuando el mensaje es extraído de la cola de
mensajes se copia desde el buffer del núcleo al espacio de direcciones del
proceso receptor Otro inconveniente que podemos encontrarnos en las colas
de mensajes sería que no es posible enviar un mensaje a varios receptores
Esto marcarlo como muy importante para que no os olvidéis No es posible
enviar un mensaje a varios receptores ¿Por qué es esto así? Porque
cuando un receptor recibe un mensaje éste es extraído de la cola con lo
que ya no se encuentra disponible para otros receptores Por eso si otro
receptor quisiera extraer ese mismo mensaje ya no lo tendría disponible en
la cola porque otro receptor lo habría cogido para él Las regiones de
memoria compartida que es lo que hemos visto en último lugar se pueden
utilizar para el intercambio rápido de pequeñas o grandes cantidades de
datos La principal desventaja que nos aportan las regiones de memoria
compartida es que para evitar condiciones de carrera es necesario utilizar
algún mecanismo de sincronización Os he puesto aquí un ejemplo que son
los semáforos y el paso de mensaje Entonces fijaros en eso que para evitar
condiciones de carrera las regiones de memoria compartida necesitan
utilizar algún tipo de mecanismo de sincronización como los que acabamos
de ver los semáforos o el paso de mensaje Luego también deciros que
existen otros tipos de mecanismos IPC no sólo los que hemos descrito antes
También nos vamos a encontrar con otros mecanismos denominados señales
Las señales son un mecanismo muy útil de notificación de eventos
Acordaros que las señales las habíamos visto en el tema 2 y aquí nos
hace el libro un inciso para que vayamos a repasar en concreto la sección
233 Podéis echarle un vistazo aquí podéis parar la clase y podéis
retroceder a esa sección 233 para refrescar los contenidos de las señales
Este mecanismo que son las señales también puede utilizarse como
mecanismo IPC para la sincronización de procesos y el libro os indica
aquí un ejemplo Por ejemplo un proceso A un proceso que le llamaremos A
puede invocar a una llamada al sistema por ejemplo la llamada al sistema
Pause para suspender su ejecución mientras otro proceso B realiza una
determinada tarea Cuando ese proceso B ha finalizado la tarea invocará una
llamada al sistema Key para enviar una determinada señal al proceso A y
que de esa manera despierte y pueda continuar su ejecución El principal
inconveniente de utilizar las señales como mecanismo de sincronización de
procesos sería el retardo que existe desde que el emisor genere una señal
hasta que el receptor la recibe Ese sería el principal inconveniente Para
enviar una señal el proceso emisor debe ser planificado para ejecución e
invocada al sistema adecuada Por ejemplo aquí esa sería la llamada al
sistema más adecuada Luego el núcleo debería ir al proceso receptor si
es que este estuviese ejecutándose y manipular su pilar usuario para poder
ejecutar el manipulador de la señal cuando ese proceso retorne a modo
usuario Tenéis esa información en la página 133 del libro y ahora vamos
a pasar a la página 134 En la página 134 os describe otro tipo del
mecanismo IPC que no hemos mencionado hasta ahora y que es un mecanismo muy
interesante Se trata del mecanismo tubería y la descripción del mecanismo
tubería sería la siguiente Una tubería sería un canal de comunicación
de una única dirección por el que se puede transmitir flujos de datos que
no estén con un tamaño máximo fijo Esa sería más o menos la
definición de tubería Un proceso emisor puede enviar datos por un extremo
de la tubería que sería lo que se denomina escribir Si la tubería vamos
a imaginárnosla así como os la dibujo aquí El proceso emisor puede
enviar datos por un extremo es decir, por aquí, por la izquierda y luego
otro proceso receptor este sería el proceso emisor Otro proceso receptor
puede recibir los datos por el otro extremo es decir, leerlos Aquí
estaría el proceso receptor que leería los datos que el emisor ha
introducido por el otro extremo de la tubería Los datos son recibidos por
orden de envío Esto significa que siguen una organización de tipo fijo
Acordaros que tipo fijo era first in, first out que significa primero en
entrar primero en salir Una vez que esos datos son leídos de la tubería
por el proceso receptor dejan de estar disponibles para ser leídos por
otros procesos receptor Es decir, cuando el emisor envía por aquí una
serie de datos para que un receptor los reciba con ellos y ya ningún otro
receptor podría leer esos mismos datos También tener en cuenta lo
siguiente si un proceso emisor intenta escribir en una tubería que esté
llena se bloquea hasta que exista espacio en la tubería De la misma manera
si un proceso receptor intenta leer en una tubería que está vacía se
bloqueará hasta que existan datos en la misma Tener en cuenta ese tipo de
restricciones para que sepáis bien manejar las tuberías Usadas como
mecanismo IPC las tuberías resultan muy eficientes pero presentan también
varios inconvenientes Os he puesto aquí algunos de ellos y son los que os
indica el libro Uno por ejemplo sería que no permiten el envío de
información a varios receptores Si os acordáis esto lo vimos antes al ver
la teoría Cuando se leen datos de una tubería esos datos son borrados De
acuerdo Y por eso ningún otro receptor podría acudir a la tubería para
volver a leer esos mismos datos Ya no existirían digamos dentro de la
tubería Un proceso que escribe en la tubería no puede especificar que
receptor debe leer los datos Esto es muy importante Fijaos que si un
proceso emisor escribe determinada información dentro de una tubería no
puede elegir que receptor será el destinatario de esa información
Entonces el emisor coloca la información y luego ya es el receptor que sea
el que accede a la misma Si un proceso emisor transmite por la tubería
varios mensajes de distinta longitud como esos datos en la tubería son un
flujo de bytes que no son estructurados el receptor no puede saber dónde
termina un mensaje y dónde empieza otro Por eso también es bastante
importante El receptor no sabe identificar cuál es el inicio y fin de un
determinado mensaje Marcar aquí como muy importante que los sistemas
operativos basados en UNIX las tuberías son gestionadas como los archivos
Los archivos los vamos a ver en el tema 5 y más en concreto en la sección
521 Por eso os he puesto aquí que lo veremos más adelante Pero hasta
aquí me interesa que sepáis que los sistemas operativos basados en UNIX
utilizan las tuberías de la misma manera que utilizan los archivos Existen
dos tipos de tuberías Son los que vamos a ver a continuación Los tenéis
en la página 134 y página 135 del libro de texto Por un lado tendríamos
las tuberías sin nombre se crean haciendo uso de la llamada al sistema
type y entre paréntesis el argumento field Esta llamada al sistema
necesita el argumento field y sería la dirección de un array entero de
dos elementos que se utilizaría para almacenar los escritores de archivo
B0 y B1 ¿Vale? Cuando esta llamada al sistema se ejecuta con éxito
devuelve el valor 0 ¿De acuerdo? Y cuando se produce algún tipo de error
y la llamada al sistema no se ejecuta con éxito, se devolvería el valor
menos 1 Que tenéis aquí Los intérpretes de comandos utilizan las
tuberías para hacer que la salida de un programa sea la entrada de otro
programa ¿De acuerdo? Esto lo vimos en el tema 1 cuando os expliqué en la
sección 151 más o menos la definición de tubería Veíamos que la salida
de un programa la podíamos enlazar con la entrada de otro programa y así
utilizar la misma línea en la consola ¿No? En este caso sería el propio
intérprete de comandos el que se encarga de vincular los descriptores de
archivos y devolver Sí, esos descriptores de archivos han sido devueltos
por la llamada al sistema pip que estamos viendo para hacer que un programa
sea el emisor y que otro sea el receptor Es decir, el propio intérprete se
encarga de denominar a un programa emisor y a otro programa receptor Se
caracterizan porque sólo pueden ser utilizadas por procesos relacionados
genealógicamente ¿De acuerdo? Además deciros que no son persistentes
¿Vale? Y no son persistentes porque son eliminadas al finalizar los
procesos que las utilizan Nosotros utilizamos una tubería y una vez que
acabamos con esa utilización pues es eliminada Eso también que lo sepáis
La implementación de este tipo de tuberías que acordaros que se denomina
tuberías sin nombre depende de cada sistema operativo basado en UNIX
Tenéis más información en esa página 134 Y por último vamos a ver las
tuberías con nombre Estas tuberías también se le suele llamar archivos
FIFO o simplemente FIFO Acordaros que esto era la denominación en inglés
de primero en entrar, primero en salir First in, first out Se crean
mediante la llamada al sistema MKNOD que veremos en la sección 552 del
tema 5 o la llamada al sistema MKFIFO ¿Vale? También se pueden crear
desde un intérprete de comandos usando los comandos homónimos Hay unos
comandos equivalentes a esas llamadas al sistema y que servirían de la
misma manera para crear esas tuberías con nombre Las tuberías con nombre
se caracterizan porque se les puede asignar una ruta dentro del sistema de
archivos Esto es muy importante Cualquier proceso aunque no sea hijo del
proceso puede acceder a la tubería si conoce la ruta de la misma y si
dispone de los permisos adecuados Lógicamente Las tuberías con nombre
también son persistentes igual que las que vimos anteriormente las
tuberías sin nombre porque continúan existiendo aunque todos los procesos
que estábamos utilizando ya hayan terminado Fijaos que aquí me he
confundido yo En las anteriores decíamos son persistentes son eliminadas
cuando finalizan los procesos que las utilizan En este caso las tuberías
con nombre si son persistentes Una vez creadas continúan existiendo aunque
todos los procesos que las hayan utilizado hubiesen acabado Para
eliminarlas hay una llamada al sistema que se puede utilizar y que sería
la llamada al sistema ONLINK un comando que sea equivalente a esa llamada
al sistema En este caso sería la forma de eliminarlas manual Y por último
para acabar el tema deciros que os viene un resumen en el apartado 3.6 que
lo podéis encontrar en la página 135 del libro y que os recomiendo que os
leáis para que podáis organizaros la teoría que hemos estudiado a lo
largo del tema que veáis un poco todo lo que hemos visto a lo largo de
este tema 3 y podéis subrayar de ahí lo que consideréis más oportuno
Luego como siempre en el apartado 3.7 os viene una serie de lecturas
recomendadas por si queréis complementar el material básico de la
asignatura También os vienen unos ejercicios de auto evaluación en el
apartado 3.8 que podéis ir haciendo que básicamente son preguntas de
teoría sobre todo los contenidos teóricos que hemos visto en el tema Y
por último la parte más importante sería la de la realización de los
ejercicios del apartado 3.9 Yo como siempre os selecciono los que a mi me
parecen más interesantes de cara al examen y los que os puede interesar
más hacer para que apliquéis los contenidos teóricos que habéis
estudiado Debéis hacer los seis ejercicios que tenéis en este caso en el
tema 3 pero yo os recomiendo que prestéis especial atención al ejercicio
3.4 al ejercicio 3.5 y al ejercicio 3.6 ¿De acuerdo? Yo voy a hacer ahora
algunos con vosotros y los que no nos den tiempo pues los podéis practicar
vosotros mismos Deciros que tenéis las soluciones en el apéndice que
viene al final del libro Entonces, en primer lugar los podéis intentar con
vuestra cuenta y si no os salen podéis ir a la última parte del libro
para ver las soluciones Entonces vamos a hacer por ejemplo el ejercicio 3.4
¿Vale? Vamos a hacer el ejercicio 3.4 para que veáis un poco como
enfrentaros a un ejercicio largo de este tipo y que podéis hacer vosotros
vosotros solos Entonces el ejercicio 3.4 es el que veis aquí, lo tenéis
ahí en ese apartado del libro también para que podáis ir viendo Este
ejercicio nos pide o nos indica mejor dicho que el directorio de trabajo
actual reside lo tengo aquí os decía que el directorio de trabajo actual
con el que trabajamos aloja los ficheros word.txt y jdie son dos ficheros
que están almacenados dentro del directorio de trabajo actual, y ahora
sabiendo eso nos pide que expliquemos o que hagamos dos apartados en el
libro me parece que este apartado A que os he puesto aquí no es bien voy a
echarle un vistazo si, os vienen los dos apartados apartado A y apartado B
entonces bueno, no es exactamente el mismo este ejercicio que tenéis aquí
vale, entonces os voy a poner mejor vamos a hacer juntos el 3.5 este lo
podéis descargar de la biblioteca y lo podéis hacer quizás sea
ligeramente pero os recomiendo que lo hagáis porque va en la misma línea
de ese ejercicio entonces vamos a hacer juntos el 3.5 este si, sería el
mismo que tenéis ahí en el libro nos pide en primer lugar que expliquemos
el significado de las cuatro sentencias que están enredadas en el código
S10 que es el que tenéis ahí vale, en el libro tenéis ese código en la
página 141 vale, este código que veis ahí es el de la página 141 y ahí
nos pide la página 139 o este ejercicio 3.5 que hagamos diferentes
acciones vale el indicado del apartado del ejercicio 3.5 sería el que veis
aquí en el apartado B explicar detalladamente el funcionamiento de este
programa si invocamos desde un intérprete de comandos la orden S10 espacio
sistemas operativos 2 de acuerdo, ese sería el enunciado que vamos a ver
aquí en la tutorial entonces tendríais la solución en esta página de
aquí, a partir de aquí estaría esa solución al apartado B vale, bien
vamos a poner aquí el código para ir marcando dos cosillas directamente
en el código y vamos a ir resolviéndolo en primer lugar deciros que
cuando escribimos esta orden en el intérprete de comandos lo que pasa es
que automáticamente se comienza a ejecutar el programa S10 vale, al
escribir eso empezaría la ejecución del programa S10 lo que pasaría es
que vamos a suponer que a la ejecución de dicho programa se le asocia el
proceso A vale, vamos a decir una vez escrita esa orden se empieza a
ejecutar el programa S10 y se le asocia el proceso A de acuerdo bien, al
asociarsele ese proceso A en primer lugar lo que hace es comprobar que
número de parámetros que se ha introducido en la línea de comandos al
invocar S10 es igual a 2 de acuerdo, la comprobación en este caso sería
positiva porque hemos introducido S10 que sería 1 y sistemas operativos 2
que sería el otro vale, entonces esa comprobación sería positiva vale,
es lo que hace esta línea de código este i lo que hace es comprobar si el
número de parámetros de esa orden es 2 vale, if b es igual a 2 como si es
correcto entraríamos en esta parte de aquí vale porque si no fuera
correcto nos iríamos a este else vale no perdonad, este de aquí haría
toda esta parte os lo pongo aquí vale eso es luego en segundo lugar se
invocaría a la llamada al sistema pipe vale, porque recordad que hemos
entrado por aquí y lo que hace esa llamada al sistema acordaros que vimos
una teoría que era crear una tubería sin nombre y comprobar que se ha
producido o que no se ha producido un error, vale comprueba si se produce o
no un error, vale es decir, devuelve el valor menos 1 vale, si devuelve el
valor menos 1 es que se ha producido un error y entonces directamente
saldríamos del programa si por el contrario esa llamada al sistema se
ejecuta con éxito vemos que devolvería 0 es decir, un valor distinto de
menos 1 y por lo tanto ya entraríamos aquí no nos saldríamos y lo que
haríamos sería crear una tubería sin nombre y en pfd se habrían
almacenado dos descriptores de fichero vale para leer de esa tubería
habría que utilizar el descriptor almacenado en pdf lo voy a poner aquí 0
para leer vamos a leer siempre de este descriptor de fichero y para
escribir en esa tubería deberíamos escribir o utilizar el pdf 1 de
acuerdo bueno, aquí utiliza pfd es igual, vale, sería el nombre de ese
descriptor de fichero de hecho creo que es una data uno de los dos sitios
está equivocado, pero sería la misma referencia nosotros lo vamos a
llamar siempre pdf para no confundir lo corregís aquí pdf y aquí dame
vale pdf en todos los sitios entonces si se produce algún error durante la
ejecución de pipe, entonces se imprimiría por pantalla esto de aquí de
acuerdo lo tenéis aquí el mensaje que veis ahí entre corchetes haría
referencia al mensaje que está asociado al identificador de error, vale
está contenido en la variable rr no bien luego qué pasaría pues que se
invocaría la llamada exit para terminar la ejecución de ese proceso a que
habíamos supuesto que se invocaba esto todo sería si la llamada a a pipe,
que estamos aquí se ejecuta con algún error vale, si hubiese algún error
lo que se hace es eso pero si esa llamada al sistema pipe se ejecuta con
éxito haría lo que viene a continuación de acuerdo sería por un lado
invocar la llamada al sistema fork, que es la que veis aquí para crear un
proceso hijo, que sería el proceso b es un proceso hijo de a, vale vamos a
dibujarlo así y esta llamada al sistema devuelve un error cero al hijo
vale y el pi de hijo al proceso padre de acuerdo ese valor en cualquier
caso se almacena en esta variable a vale, que veis aquí porque es la
salida de la llamada al sistema fork es el planificador el que decide que
proceso se ejecuta a continuación el padre o el hijo veis aquí que en el
caso de que la a valga cero estaremos ejecutando el hijo, vale y por el
contrario ejecutaríamos este else que sería que vamos a ejecutar el
padre, de acuerdo supongamos que en primer lugar se ejecuta el proceso
padre, vale y cuando se acaba pues se empezaría el proceso hijo entonces
primero se cierra el fichero con descriptor pdf cero este vale se cerraría
puesto que no lo va a utilizar vale, lo que tenemos aquí lo voy a marcar
en amarillo lo que va pasando luego se invoca la llamada al sistema gray
para escribir en el fichero con descriptor pdf uno esto que veis aquí son
las operaciones de escritura de la tubería luego vamos a escribir ahí los
diez primeros bytes del segundo parámetro introducido por la línea de
orden de acuerdo es decir, escribe en la tubería system o vale, los diez
primeros bytes pues serían como si dijésemos los diez primeros caracteres
vale, tres cuatro cinco seis siete, ocho nueve y diez vale, esos serían
los diez primeros bytes esos diez primeros bytes se escribirían dentro de
la tubería vale y por último se cerraría el descriptor de fichero pdf
uno puesto que no se va a escribir más en esa tubería por último
escribiría en la pantalla la palabra mensaje y finalmente se invocaría la
llamada al sistema exit para finalizar vale eso sería lo que se hace en
primer lugar ejecutar el proceso padre vamos a poner aquí que es el
proceso padre y después, a continuación hemos supuesto que se ejecuta el
proceso hijo que es este que está en la parte superior ese proceso hijo lo
que hace en primer lugar es cerrar el fichero con descriptor pdf uno close
pdf uno vale y ejecutar un bucle while para que en cada pasada de ese bucle
se lea un byte de la tubería y se escriba por pantalla ese bucle
finalizaría cuando no quedan más bytes por leer de la tubería bueno
entonces vamos a ver que lo que pasa aquí es que se va leyendo cada uno de
estos caracteres que son los que están dentro de la tubería y ese bucle
finalizaría cuando ya hubiese más caracteres dentro de la tubería según
se vaya leyendo se van escribiendo por pantalla vale entonces aquí por
pantalla se ha escrito esto que os pongo en negro que es lo que había
dentro de la tubería sistemas barra baja o luego a continuación se
escribiría en la pantalla un salto de línea que es lo que tenemos aquí
que os pongo amarillo esta línea de aquí luego como siempre cerramos el
descriptor pdf cero vale aquí se trata en el documento aquí donde pone
pdf uno deberéis poner pdf cero vale anotarlo por ahí para que lo
tengáis en cuenta como no se va a leer más en la tubería porque ya hemos
escrito todo el mensaje que nos interesa pues lo cerramos y por último
mostramos como en el caso anterior la palabra mensaje y por último
invocaríamos la llamada sistema exit para finalizar de acuerdo deciros que
si se hubiese planificado el proceso hijo antes que el proceso padre vale
vemos que ahora lo que hemos hecho es primero el padre y luego el hijo
deciros que si se hubiese hecho al revés hubiese quedado bloqueado al
intentar leer en una tubería vacía vale se habría bloqueado al querer
leer una tubería vacía entonces es importante leerle a la hora de hacer
el examen tenerlo en cuenta para que no se produzca ese tipo de bloqueo
esto es así porque sólo cuando el proceso padre escriba la tubería el
proceso hijo sería desbloqueado vale si un proceso hijo intenta leer de
una tubería vacía se bloquea y sólo se desbloquea cuando el padre
escribe de nuevo algo en esa tubería y deja de estar vacía en ese momento
sería el planificador el que se encargase de decidir si continúa con la
ejecución del padre o con la del hijo estas tareas siempre son las que
hace el planificador vale entonces dependiendo de si lo suponéis de una
manera o de otra en el examen las salidas que os encontraríais por
pantalla serían las que os pongo aquí vale la que hemos hecho nosotros
sería la traza 1 es decir que en primer lugar apareciese la palabra
mensaje después apareciese lo que hemos leído de la tubería que es la
palabra sistemas barra baja o y por último de nuevo la palabra mensaje
pero si ejecutamos primero el hijo y después el padre que es lo contrario
que lo que hemos visto en clase se escribiría en primer lugar la palabra
sistemas barra baja o y en segundo lugar la palabra mensaje y por último
la palabra mensaje habría un ligero cambio pero bueno que sepáis que se
puede hacer igual y que lo tengáis muy en cuenta a la hora de hacer el
examen para que escribáis la traza correcta que den al caso en vuestra
elección y esta sería la forma de hacer el ejercicio 3.5 que os he
recomendado vale en la primera parte de este ejercicio 3.5 os he puesto
otro apartado que no os viene del libro si queréis echarle un vistazo os
servirá para entender con más detalle las sentencias que os vienen
numeradas entre corchetes la 1, la 2, la 3 y la 4 aunque no os lo pida la
actividad 3.5 os recomiendo que lo hagáis descargándoos estos PDF que os
he puesto en la video tutorial os quedaría como deber es hacer el
ejercicio 3.4 y el 3.6 si tenéis alguna duda pues podréis ver la
solución como decía antes en el apéndice del libro al final y hasta
aquí sería todo referente al tema 3 de la asignatura de acuerdo por mi
parte nada más y nos vemos en el siguiente tutorial un saludo