diff --git "a/so2425/comunicaci\303\263n_mediante_paso_de_mensajes.html" "b/so2425/comunicaci\303\263n_mediante_paso_de_mensajes.html" index de8b5be..6c851f6 100644 --- "a/so2425/comunicaci\303\263n_mediante_paso_de_mensajes.html" +++ "b/so2425/comunicaci\303\263n_mediante_paso_de_mensajes.html" @@ -1286,12 +1286,12 @@
El ejemplo en mqueue-server.cpp y en otros ejemplos de este capítulo, utiliza señales para manejar SIGINT
, SIGTERM
y para mostrar la hora periódicamente.
-El código dedicado a eso está en timeserver.c y se comparte entre todos los ejemplos.
-En todos los casos se evita usar SA_RESTART
porque interesa que el proceso interrumpa lo que esté haciendo cuando llegue una señal para terminar.
El ejemplo en mqueue-server.cpp y en otros ejemplos de este capítulo, utiliza señales para mostrar la hora periódicamente.
+El código dedicado a eso está en timeserver.cpp y se comparte entre todos los ejemplos.
+En todos los casos se usa SA_RESTART
porque interesa que se maneje la señal de SIGARLM
para mostrar la hora, sin interrumpir cualquier llamada al sistema en la que puede estar esperando el proceso cuando llegue la señal.
En signals.c hay un programa de ejemplo que muestra cómo manejar las señales del sistema y que sirve para ver cómo funcionan. +
En signals.cpp hay un programa de ejemplo que muestra cómo manejar las señales del sistema y que sirve para ver cómo funcionan.
Solo hay que ejecutarlo y luego enviarle señales con el comando kill
desde otra terminal.
En este caso si se usa SA_RESTART
, porque el programa debe estar esperando la pulsación de una tecla con getc()
y no nos interesa que deje de hacerlo cuando llegue una señal.
Por otro lado, las tuberías con nombre permiten que un proceso se comunique con cualquier otro, solo con conocer la ruta de la tubería. -En fifo-server.c tenemos un ejemplo de un programa que muestra la hora del sistema de forma periódica, mientras espera órdenes de una tubería que sirve de canal de control remoto. -Los programas en fifo-client.c y fifo-client.cpp pueden conectarse a esa tubería y mandar el comando que hace terminar fifo-server.c.
+En fifo.cpp tenemos un ejemplo de un programa que muestra la hora del sistema de forma periódica, mientras espera órdenes de una tubería que sirve de canal de control remoto. +El programa en fifo-control.cpp puede conectarse a esa tubería y mandar el comando que hace terminar fifo.cpp.En shared-memory-server.c y shared-memory-client.cpp se puede ver el ejemplo de un programa que muestra periódicamente la hora del sistema. -En este caso controlado por otro mediante memoria compartida. -Ambos programas usan la clase definida en shared_memory.hpp para gestionar el objeto de memoria compartida. -Sus métodos muestran de forma práctica cómo utilizar las llamadas al sistema comentadas.
+En shared-memory.cpp se puede ver el ejemplo de un programa que muestra periódicamente la hora del sistema. +En este caso controlado por shared-memory-control.cpp mediante memoria compartida.
En Microsoft Windows también se utiliza CreateFileMapping() para crear el objeto de memoria compartida con nombre. diff --git "a/so2425/planificaci\303\263n_de_la_cpu.html" "b/so2425/planificaci\303\263n_de_la_cpu.html" index 350b7cc..7c10c0e 100644 --- "a/so2425/planificaci\303\263n_de_la_cpu.html" +++ "b/so2425/planificaci\303\263n_de_la_cpu.html" @@ -1914,11 +1914,11 @@
de forma que siempre haya suficientes porciones para que cada proceso pueda tener al menos una, limitando por debajo el número de porciones a repartir a \$\text{floor}(L / M)\$.
+de forma que siempre haya suficientes porciones \$M\$ para que cada proceso pueda tener al menos una, limitando por debajo el número de porciones a repartir a \$\text{floor}(L / M)\$.
Cuando se escoge un proceso para su ejecución, se calcula el cuanto real \$t_{i}\$ durante el que se le asignará la CPU:
@@ -1931,6 +1931,10 @@de forma que se reparten las \$g\$ porciones entre los \$n\$ procesos.
Si hay muchos procesos, \$g = n\$, por lo que a cada proceso se le asigna un tiempo de CPU de \$M\$. +Si hay pocos procesos, \$g = \text{floor}(L / M)\$, por lo que a cada proceso se le asignan varias porciones \$M\$ de tiempo de CPU del periodo \$L\$.
+Hay varios aspectos en la creación de los procesos que pueden variar de un sistema operativo a otro. -Uno de ellos es cómo obtienen los procesos hilos los recursos que necesitan para hacer su trabajo.
+Uno de ellos es cómo obtienen los procesos hijos los recursos que necesitan para hacer su trabajo.Fundamentalmente existen dos alternativas:
@@ -1192,7 +1192,7 @@El código fuente completo de este ejemplo está disponible en createprocess.c.
+El código fuente completo de este ejemplo está disponible en createprocess.cpp.
El código fuente completo de este ejemplo está disponible en fork.c.
+El código fuente completo de este ejemplo está disponible en fork.cpp.
El código fuente completo de este ejemplo está disponible en fork-exec.c.
+El código fuente completo de este ejemplo está disponible en fork-exec.cpp.
En shared-memory-server.c está el ejemplo completo de un programa que muestra periódicamente la hora del sistema y que puede ser controlado remotamente, mediante memoria compartida, con un cliente como el de shared-memory-client.cpp.
+En shared-memory.cpp está el ejemplo completo de un programa que muestra periódicamente la hora del sistema y que puede ser controlado remotamente, mediante memoria compartida, con un programa como el de shared-memory-control.cpp.
Para enviar los mensajes entre el cliente y el servidor, en la memoria compartida se reserva hueco para un búfer en el que el cliente copia el comando que quiere enviar y para dos semáforos:
+Para enviar los mensajes entre ambos programas, en la memoria compartida se reserva hueco para un búfer, en el que el programa de control copia el comando que quiere enviar, y para dos semáforos:
command_buffer
está vacío, así que se inicializa a 1.
-El cliente usa sem_wait() en este semáforo antes de escribir un nuevo comando en command_buffer
:
+El programa de control usa sem_wait() en este semáforo antes de escribir un nuevo comando en command_buffer
:
Si el semáforo está a 0, el cliente pasa y escribe el comando. +
Si el semáforo está a 0, el programa de control pasa y escribe el comando.
Después llama a sem_post() en ready
.
Si el semáforo está a 1, el cliente queda bloqueado y tiene que esperar a que el servidor use sem_post() sobre el mismo semáforo. -El servidor lo hace después de leer el comando para interpretarlo.
+Si el semáforo está a 1, el programa de control queda bloqueado y tiene que esperar a que el servidor use sem_post() sobre el mismo semáforo. +El programa controlado lo hace después de leer el comando para interpretarlo.
command_buffer
tiene un comando, así que se inicializa a 0.
-El servidor usa sem_wait() en este semaforo antes de leer el comando en command_buffer
para interpretarlo:
+El programa controlado usa sem_wait() en este semaforo antes de leer el comando en command_buffer
para interpretarlo:
Si el semáforo está a 0, el cliente pasa y lee el comando. +
Si el semáforo está a 0, el programa de control pasa y lee el comando.
Después llama a sem_post() en empty
.
Si el semáforo está a 1, el servidor queda bloqueado y tiene que esperar a que el cliente use sem_post() sobre el mismo semáforo.
-El cliente lo hace después de escribir un nuevo comando en command_buffer
.
Si el semáforo está a 1, el programa controlado queda bloqueado y tiene que esperar a que el programa de control use sem_post() sobre el mismo semáforo.
+El programa de control lo hace después de escribir un nuevo comando en command_buffer
.
El detalle de cómo cliente y servidor usan ambos semáforos, se puede ver en el código de shared-memory-client.cpp y shared-memory-server.c, respectivamente.
+El detalle de cómo ambos programas usan los semáforos, se puede ver en el código de shared-memory-control.cpp y shared-memory.cpp, respectivamente.
Finalmente, para resolver el problema del productor-consumidor tenemos que considerar que:
diff --git a/so2425/sistema_de_archivos.html b/so2425/sistema_de_archivos.html index 8bbf8de..61afe0e 100644 --- a/so2425/sistema_de_archivos.html +++ b/so2425/sistema_de_archivos.html @@ -1719,20 +1719,20 @@En filelock-server.c y filelock-client.cpp se puede ver un ejemplo similar al de capítulos anteriores, pero usando en esta ocasión bloqueo de archivos.
-El servidor filelock-server.c es un programa que muestra periódicamente la hora del sistema.
-Mientras que el cliente filelock-client.cpp, simplemente envía una señal SIGTERM
al servidor cuando queremos que termine.
-Para que el cliente conozca el PID del servidor —de entre todos los procesos en ejecución en el sistema— el servidor escribe su PID en un archivo en una ubicación conocida por ambos.
En filelock-server.c y filelock-stop.cpp se puede ver un ejemplo similar al de capítulos anteriores, pero usando en esta ocasión bloqueo de archivos.
+El programa filelock-server.c hace de servidor proporciona periódicamente la hora del sistema.
+Mientras que el programa filelock-stop.cpp, simplemente envía una señal SIGTERM
a filelock-server.c cuando queremos que termine.
+Para que filelock-stop.cpp conozca el PID de filelock-server.c —de entre todos los procesos en ejecución en el sistema— este último escribe su PID en un archivo en una ubicación conocida por ambos.
Como el cliente lee el archivo con una única operación read() y el servidor lo escribe con una única operación write(), no hace falta el uso de bloqueo de archivos para sincronizarlos. -Gracias a la semántica de coherencia POSIX, el cliente no puede leer el archivo en medio de la escritura. -Es decir, o ve el PID completo escrito por el servidor o no ve ninguno.
+Como filelock-stop.cpp lee el archivo con una única operación read() y filelock-server.c lo escribe con una única operación write(), no hace falta el uso de bloqueo de archivos para sincronizarlos. +Gracias a la semántica de coherencia POSIX, el filelock-stop.cpp no puede leer el archivo en medio de la escritura. +Es decir, o ve el PID completo escrito por filelock-server.c o no ve ninguno.
Pero si puede darse el caso de que se ejecuten varios servidores al mismo tiempo. +
Pero si puede darse el caso de que se ejecuten varios servidores filelock-server.c al mismo tiempo. Cada uno debe comprobar si archivo existe y, si es así, leer el PID que contiene y comprobar si hay un proceso con ese mismo PID. -Si el archivo no existe o no encuentra un proceso con ese PID, debe entender que es el nuevo servidor y escribir su PID en el archivo, para que lo encuentre el cliente. +Si el archivo no existe o existe no encuentra un proceso con el PID indicado, debe entender que es el nuevo servidor y escribir su PID en el archivo, para que lo encuentre el programa de control. En caso contrario, debe terminar.