fix: definición de términos en secciones

content/C02-tipos_de_sistemas.adoc

@@ -25,7 +25,9 @@ La mayor diferencia entre los superordenadores y los _mainframes_<<Wikipedia-Mai
 Los _mainframes_ aparecieron a finales de la década de los 50 del siglo pasado y han seguido evolucionando hasta la actualidad, por lo que dentro de este tipo de sistemas nos encontramos con varias categorías.
 
 === Sistemas de procesamiento por lotes
-(((sistema, procesamiento por lotes)))(((sistema, batch)))
+
+(((sistema, procesamiento por lotes)))
+(((sistema, batch)))
 Los primeros _mainframes_ eran enormes máquinas operadas desde una consola y conectados a lectores de tarjetas perforadas, dispositivos de cinta e impresoras.
 
 [NOTE]
@@ -70,6 +72,7 @@ Si solo se puede ejecutar un programa la vez, cuando el programa solicita una op
 Este desaprovechamiento de la CPU es peor cuanto más rápida es la CPU respecto a los dispositivos de E/S.
 
 === Sistemas multiprogramados
+
 (((sistema, multiprogramado)))
 La solución al inconveniente de los sistemas de procesamiento por lotes con la E/S fue que los programas no accedieran directamente al dispositivo de E/S, sino que, en su lugar, solicitaran la operación al *monitor del sistema* para que este la solicitara al hardware.
 Así el sistema operativo —como podemos comenzar a llamarlo— tiene la oportunidad de sustituir el programa en la CPU por otro, mientras la operación de E/S se completa.
@@ -114,6 +117,7 @@ Para operar de la forma descrita es necesario que el sistema operativo realice t
 Un ejemplo de este tipo de sistemas operativos es el IBM OS/360, que fue lanzado en 1966 para utilizarlo en los _mainframes_ IBM System/360 (véase el <<sect-historia-segunda-generación>>).
 
 === Sistemas de tiempo compartido
+
 (((sistema, tiempo compartido)))
 Los sistemas multiprogramados ofrecían un uso más eficiente de la CPU, pero no eran capaces de proporcionar interacción directa con los usuarios.
 Los programadores seguían teniendo que entregar los trabajos al operador y espera a que este les devolviera los resultados.
@@ -183,6 +187,7 @@ Al igual que lo son los _mainframes_ modernos y muchos sistemas operativos actua
 ====
 
 == Sistemas de escritorio
+
 (((sistema, escritorio)))
 En la década de los 70 del siglo pasado también aparecieron las primeras CPU en microprocesadores y con estas llegaron las *microcomputadoras* o *microordenadores*.
 Las primeras *((microcomputadora))s* no incluían teclado ni monitor y se programaban usando interruptores y ledes ubicados en el frontal de la unidad.
@@ -227,14 +232,17 @@ Para más información, véase el <<_criterios_de_planificación>>.
 Son muchos los ejemplos de sistemas operativos en esta categoría. Van desde CP/M —lanzado en 1977— hasta los actuales GNU/Linux, Microsoft Windows y Apple macOS, pasando por MS-DOS, IBM OS/2 y todas las versiones anteriores de Microsoft Windows (véase el <<sect-historia-cuarta-generación>>).
 
 == Sistemas de mano
-(((sistema, de mano)))(((sistema, móvil)))
+
+(((sistema, de mano)))
+(((sistema, móvil)))
 Con el nombre genérico de **sistemas de mano** —del inglés _handheld_— hacemos referencia a las _tablets_, _smartphones_, lectores de libros electrónicos y otro sistemas móviles y portátiles.
 Los desarrolladores de aplicaciones y sistemas de mano deben enfrentarse a diversos desafíos, originados por el tamaño limitado de los dispositivos y la alimentación mediante el uso de baterías.
 Debido a esas limitaciones, muchos sistemas de mano tienen poca cantidad de memoria, procesadores lentos —en comparación con sus equivalentes de escritorio— y pantallas más pequeñas.
 
 En el diseño del sistema operativo suele primar la facilidad de uso y buscar un buen equilibrio entre rendimiento y tiempo de vida de la batería.
 
 == Sistemas multiprocesador
+
 (((sistema, multiprocesador)))
 Un *sistema multiprocesador* es aquel ordenador hay procesadores interconectados que comparten el bus del sistema, el reloj y, en ocasiones la memoria, y los periféricos.
 
@@ -278,6 +286,7 @@ Por lo que, aunque sobre el papel esta arquitectura ofrecía gran rendimiento, a
 ====
 
 == Sistemas distribuidos
+
 (((sistema, distribuido)))
 En la actualidad es común el uso de redes para interconectar ordenadores individuales —por ejemplo Internet o la red de área local de una oficina— cada uno equipado con su procesador, su memoria, sus dispositivos de almacenamiento, su fuente de alimentación, etc.
 En las redes de ordenadores los procesadores de dichos ordenadores se comunican con otros procesadores a través de líneas de comunicación, como: redes Ethernet, líneas telefónicas o wifi.
@@ -338,6 +347,7 @@ Para más información, véase el http://www.cs.vu.nl/pub/amoeba/[sitio web de A
 ====
 
 == Sistemas en clúster
+
 (((sistema, clúster)))
 Como los sistemas distribuidos, los *sistemas en clúster* interconectar ordenadores individuales.
 Sin embargo, generalmente se acepta que los *sistemas en clúster* comparten el almacenamiento y estén conectados por medio de una red local, condiciones que no tienen por qué darse en los sistemas distribuidos.
@@ -360,6 +370,7 @@ También es muy utilizado en servidores de Internet —como servidores web, corr
 En estos casos el balanceador de carga realiza su trabajo repartiendo las conexiones de los usuarios entre los servidores del clúster.
 
 == Sistemas de tiempo real
+
 (((sistema, tiempo real)))
 Los **sistemas de ((tiempo real))** se utilizan cuando existen requerimientos estrictos de tiempo en la ejecución de ciertas tareas o en el procesamiento de flujos de datos.
 

content/C04-componentes.adoc

@@ -15,6 +15,7 @@ Lo que veremos en este capítulo es un esquema de los más comunes a la mayoría
 
 [[sect-componente-gestión-de-procesos]]
 == Gestión de procesos
+
 (((gestión, procesos)))
 La gestión de los procesos es un elemento central de todo sistema operativo:
 
@@ -61,6 +62,7 @@ El componente de gestión de procesos es el responsable de las siguientes activi
 * Proporcionar mecanismos para el tratamiento de interbloqueos.
 
 == Gestión de la memoria principal
+
 (((gestión, memoria)))
 La memoria principal es un recurso fundamental para las operaciones de cualquier sistema operativo moderno.
 Esto es así porque generalmente es el único almacenamiento al que la CPU tiene acceso directo.
@@ -81,6 +83,7 @@ El componente de gestión de la memoria debe asumir las siguientes responsabilid
 * Asignar y liberar espacio de la memoria principal según sea necesario.
 
 == Gestión del sistema de E/S
+
 (((gestión, sistema de E/S)))
 El *sistema de E/S*(((sistema, de E/S))) hace de interfaz con el hardware, oculta las peculiaridades del hardware al resto del sistema.
 
@@ -193,6 +196,7 @@ Cuando una aplicación termina de enviar el trabajo, el archivo correspondiente
 Así no hay acceso simultáneo al dispositivo por parte de varios procesos, mientras que estos pueden entregar el trabajo y continuar con su trabajo sin esperar a que la impresora esté disponible.
 
 == Gestión del almacenamiento secundario
+
 (((gestión, almacenamiento secundario)))
 Dentro de los dispositivos de E/S, los dedicados al almacenamiento secundario —como discos duros, memorias USB o lectores de DVD-ROM— merecen un tratamiento especial.
 
@@ -211,6 +215,7 @@ El gestor del almacenamiento secundario es el responsable de:
 * Planificar el acceso a los dispositivos, de tal forma que se ordenen las operaciones de forma eficiente.
 
 == Gestión del sistema de archivos
+
 (((gestión, sistema de archivos)))
 Los ordenadores pueden almacenar información en diferentes tipos de medios físicos —por ejemplo en discos duros magnéticos, CD/DVD-ROM, memorias USB o SSD— cada uno de los cuales tiene características propias.
 El acceso a cada tipo de medio es controlado por un dispositivo —por ejemplo el controlador de disco o la unidad de DVD-ROM— que también tiene características propias.
@@ -243,6 +248,7 @@ El sistema de archivos utiliza al gestor del almacenamiento secundario y al sist
 * Hacer copias de seguridad de los archivos en sistemas de almacenamiento estables y seguros.
 
 == Gestión de red
+
 (((gestión, red)))
 El componente de red se responsabiliza de la comunicación con otros sistemas interconectados mediante una red de ordenadores —por ejemplo, en Internet o en la red de área local de una oficina—.
 

content/C05-servicios.adoc

@@ -50,6 +50,7 @@ Por eficiencia y protección un usuario, normalmente los procesos no puede tener
 Por ejemplo, puede haber errores del hardware —como fallos de energía o errores en la memoria— en la E/S —como errores de paridad o falta de papel en la impresora— y en los programas de usuario —como desbordamientos aritméticos o accesos ilegales a la memoria—.
 
 == Interfaz de usuario
+
 (((interfaz, de usuario)))
 La *interfaz de usuario* es un servicio fundamental para todos los sistemas diseñados para que los usuarios interactúen con ellos directamente, por lo que nos vamos a detener un poco más en él.
 

content/C06-api.adoc

@@ -12,6 +12,7 @@ Un sistema operativo proporciona un entorno controlado para la ejecución de pro
 Dicho entorno debe proporcionar ciertos servicios que pueden ser accedidos por los programas a través de una *interfaz de programación de aplicaciones* o *((API))* (_Application Programming Interface_).
 
 == Interfaces de programación de aplicaciones
+
 (((interfaz, programación de aplicaciones)))
 Algunas de las API disponibles para los desarrolladores de aplicaciones son Windows API y POSIX.
 
@@ -119,6 +120,7 @@ Las definiciones por defecto incluyen: POSIX.1-2008, ISO C99 y algunas funcional
 Activa `_DEFAULT_SOURCE` y extensiones específicas de los sistemas GNU.
 
 == Llamadas al sistema
+
 (((llamada al sistema)))
 Para un programa, acceder a los servicios del sistema operativo no es tan sencillo como invocar una función.
 Para invocar una función, un programa necesita conocer la dirección en la memoria del punto de entrada de dicha función —es decir, la ubicación de su primera instrucción—.
@@ -206,6 +208,7 @@ En cualquier caso, sea cual sea el método utilizado, el sistema operativo es re
 A fin de cuentas, una de las funciones del sistema operativo es el control de dichos procesos.
 
 == Librería del sistema
+
 (((librería, del sistema)))
 Las *llamadas al sistema* proporcionan una interfaz con la que los procesos pueden invocar los servicios que el sistema operativo ofrece.
 El problema es que como se hacen mediante instrucciones en lenguaje ensamblador (véase el <<ejemplo-linux-mips-syscall>>) no son demasiado cómodas de utilizar.
@@ -235,6 +238,7 @@ Por lo tanto, la invocación de las funciones de la librería del sistema se rea
 ====
 
 == Librería estándar
+
 (((librería, estándar)))
 Lenguajes distintos de C y {cpp} pueden tener difícil usar las funciones de la librería del sistema.
 Pero de alguna forma deben poder hacerlo, porque sus programadores necesitan acceso a los servicios que ofrece el sistema operativo.

content/C07-modo_dual.adoc

@@ -173,6 +173,7 @@ Por ejemplo, un programa mal desarrollado que entra en un bucle infinito, del qu
 Obviamente, las instrucciones que pueden modificar el contenido del temporizador son instrucciones privilegiadas.
 
 == Máquinas virtuales
+
 (((máquina virtual)))
 Utilizando las técnicas comentadas anteriormente, el sistema operativo crea a los procesos la ilusión de que se ejecutan en su propio procesador y memoria principal, aunque realmente los estén compartiendo con otros procesos.
 Obviamente, los procesos saben que hay un sistema operativo que los supervisa, porque no pueden acceder directamente al hardware, sino que deben solicitar los distintos recursos a través de las llamadas al sistema.

content/C08-estructura.adoc

@@ -12,8 +12,9 @@ Ya hemos discutido anteriormente acerca de los componentes más comunes en un si
 En esta sección comentaremos cómo se clasifican los distintos sistemas operativos según la organización e interconexión de sus componentes.
 
 == Estructura sencilla
-(((estructura, sencilla)))
+
 ====
+(((estructura, sencilla)))
 Los sistemas con *estructura sencilla* se caracterizan por: 
 
 * No tener una estructura bien definida.
@@ -50,8 +51,9 @@ Tanto MS-DOS como UNIX eran originalmente sistemas pequeños y simples, limitado
 Lo cierto es que con mejor soporte del hardware se puede dividir el sistema operativo en piezas más pequeñas y apropiadas que las del MS-DOS y el UNIX original.
 
 == Estructura en capas
-(((estructura, en capas)))
+
 ====
+(((estructura, en capas)))
 Los sistemas con *estructura en capas* se caracterizan por: 
 
 * La funcionalidad se divide en capas, de tal forma que una capa solo utiliza funciones y servicios de la capa inmediatamente inferior y lo hace a través de una interfaz bien definida.
@@ -98,8 +100,9 @@ Esto limita mucho las ventajas de esta técnica porque no permite compartimentar
 ====
 
 == Microkernel
-(((estructura, microkernel)))(((microkernel)))
 ====
+(((estructura, microkernel)))
+(((microkernel)))
 Los sistemas con *estructura microkernel* se caracterizan por: 
 
 * Eliminar todos los componentes no esenciales del núcleo e implementarlos como procesos de usuario.

content/C09-procesos.adoc

@@ -115,6 +115,7 @@ Como en el caso del estado *nuevo*, este estado existe porque terminar un proces
 El diagrama de estados de los procesos, con las transiciones posibles entre ellos, se muestra en la <<fig-diagrama-estado-proceso>>.
 
 == Bloque de control de proceso
+
 (((bloque, de control, proceso)))
 El *bloque de control de proceso* o *((PCB))* (_Process Control Block_) es una estructura de datos que representa a cada proceso en el sistema operativo y que guarda información sobre su estado de actividad actual.
 
@@ -148,6 +149,7 @@ Aquí se incluye la cantidad de CPU usada, límites de tiempo en el uso de la CP
 Incluye la lista de dispositivos de E/S reservados por el proceso, la lista de archivos abiertos, etc.
 
 == Colas de planificación
+
 (((cola, planificación)))
 En los sistemas operativos hay diferentes *colas de planificación* para los procesos en distintos *estados*.
 

content/C10-ipc.adoc

@@ -249,6 +249,7 @@ Los sistemas que optan por esta solución suelen disponer de algún mecanismo pa
 La elección puede ser aleatoria, mediante algún algoritmo, por ejemplo, por turnos o el siguiente proceso en obtener la CPU, a criterio del planificador de la CPU.
 
 == Buffering
+
 (((buffering)))
 Los mensajes intercambiados por enlace de comunicación se almacenan en una cola temporal, a la espera de ser enviados o, tras recibirlos, a la espera de que los reclame el proceso.
 

content/C12-hilos.adoc

@@ -107,8 +107,8 @@ Otros lenguajes proporcionan un *librería de hilos* dentro de su *librería est
 El soporte de hilos en un sistema operativo se puede proporcionar a *nivel de usuario* o a *nivel de núcleo*.
 
 === Hilos a nivel de usuario
-(((hilo, usuario)))
 
+(((hilo, usuario)))
 El soporte de *hilos a nivel de usuario* se implementan mediante un *librería de hilos* en el espacio de usuario, junto al código del programa y los datos del proceso, sin requerir ningún soporte especial por parte del núcleo del sistema operativo.
 Por tanto, como se puede observar en el lado derecho de la <<fig-comparación-soporte-de-hilos>>, estos hilos existen desde el punto de vista del proceso y del programa que ejecuta, pero no para el sistema operativo.
 El planificador de la CPU asigna tiempo de CPU a los procesos, mientras que la *librería de hilos* de cada proceso reparte el tiempo de ejecución del proceso entre los diferentes hilos de este.
@@ -120,8 +120,8 @@ image::{chapdir}/comparación_soporte_de_hilos.svg[]
 Como el código y los datos de la librería residen en el espacio de usuario, invocar una función de la misma se reduce a una simple llamada a una función, evitando el coste de hacer llamadas al sistema.
 
 === Hilos a nivel de núcleo
-(((hilo, núcleo)))
 
+(((hilo, núcleo)))
 Se habla de *hilos a nivel de núcleo*, cuando el núcleo del sistema es el encargado de ofrecer el soporte multihilo.
 El código y los datos de la *librería de hilos*, mediante la cual los programadores pueden solicitar la creación y gestión de los hilos, reside en el espacio del núcleo.
 Por tanto, para invocar una función de la *librería de hilos* es necesario hacer una llamada al sistema.
@@ -151,8 +151,9 @@ Aquí entendemos por *hilos de núcleo* a estas secuencias de instrucciones tal
 Mientras que el concepto de *hilos de núcleo* corresponde con como las ve el núcleo del sistema.
 
 === Muchos a uno (N:1)
-(((muchos a uno)))(((modelo, muchos a uno)))
 
+(((muchos a uno)))
+(((modelo, muchos a uno)))
 En el modelo *muchos a uno* muchos *hilos de usuario* son mapeados en *un único hilo de núcleo*.
 El planificador de la CPU en el núcleo reparte el tiempo de CPU entre los diferentes *hilos de núcleo* en el sistema, mientras que la *librería de hilos* en cada proceso reparte el tiempo de ejecución del *hilo de núcleo* del proceso entre múltiples *hilos de usuario* (véase la <<fig-modelo-muchos-a-uno>>).
 
@@ -241,8 +242,9 @@ En Java 1.1 era el único modelo soportado —ya que los hilos se implementaban
 Otras implementaciones de este modelo son las https://docs.microsoft.com/en-us/windows/win32/procthread/fibers[fibras] y https://docs.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling[UMS] de Windows API, {stackless_python} y http://www.gnu.org/software/pth/[GNU Portable Threads].
 
 === Uno a uno (1:1)
-(((uno a uno)))(((modelo, uno a uno)))
 
+(((uno a uno)))
+(((modelo, uno a uno)))
 En el modelo *muchos a uno* un *hilo de usuario* se mapea en *un único hilo de núcleo*.
 
 Por lo general, este modelo corresponde al caso de los sistemas que solo soportan *hilos a nivel de núcleo*.
@@ -279,8 +281,9 @@ El modelo *uno a uno* se utiliza en la mayor parte de los sistemas operativos mu
 Linux, Microsoft Windows —desde Windows 95— {solaris} 9 y superiores, macOS y la familia de UNIX BSD; son ejemplos de sistemas operativos que utilizan el modelo *uno a uno*.
 
 === Muchos a muchos (M:N)
-(((muchos a muchos)))(((modelo, muchos a muchos)))
 
+(((muchos a muchos)))
+(((modelo, muchos a muchos)))
 En teoría debería ser posible aprovechar lo mejor de los dos modelos anteriores con una *librería de hilos* en el núcleo, para crear *hilos de núcleo*, y otra en el espacio de usuario, para crear *hilos de usuario*.
 Así los desarrolladores pueden utilizar la *librería de hilos* en el espacio de usuario para crear tantos hilos como quieran y que estos se ejecuten sobre los *hilos de núcleo* de su proceso.
 
@@ -645,6 +648,7 @@ int return_code = pthread_setcanceltypr(
 Se pueden cambiar entre estado y tipo de cancelación en cualquier momento, según lo que encaje mejor con las características de las distintas partes del código.
 
 ==== Cancelación asíncrona
+
 (((cancelación, asíncrona)))
 Por los motivos comentados anteriormente, no es recomendable la *cancelación asíncrona*, a menos que estemos muy seguros de que no puede causar problemas.
 Uno de los pocos casos con los que es compatible es en bucles 100% dedicados a ejecutar cálculos en la CPU, como el siguiente: 
@@ -668,6 +672,7 @@ El estándar POSIX solo indica que las funciones {pthread_setcancelstate} y {pth
 En general, no se puede llamar a otras funciones de la librería del sistema de forma segura en un hilo cancelable asíncronamente.
 
 ==== Cancelación en diferido
+
 (((cancelación, en diferido)))
 Por tanto, la *cancelación en diferido* es la mejor alternativa.
 Con este tipo de cancelación, la terminación del hilo ocurre en puntos concretos del código.