Hilos.

En sistemas operativos los hilos son miniprocesos, es decir procesos dentro de procesos; con la
finalidad entre ellas que se puedan ejecutar varias actividades a la vez en una aplicación. Es decir,
se descompone una aplicación en varios hilos secuenciales que se ejecutan casi todos a la vez ; es
decir es como procesos en paralelo pero con la diferencia es que acá se comparten los espacios de
direcciones de memoria y los datos entre ellos; lo que no ocurre con procesos en paralelo
propiamente dicho que tienen diferentes espacios de direcciones de memoria.

En una arquitectura de servidores, se visibilizan de esta manera:

Estos hilos son más ligeros que los procesos por lo que son más fáciles de crear y luego de destruir.
Ellos son muy útiles en sistemas donde hay varios CPU y se logra un paralelismo verdadero.

El soporte a los hilos puede ser:

A nivel de usuario (user threads): Los hilos de usuario se proveen por encima del kernel y se
administran sin su soporte. Colocar el paquete de hilos completamente en espacio de usuario. El
kernelcno sabe nada acerca de ellos. En lo que al kernel concierne, está administrando procesos
ordinariosccon un solo hilo. La primera ventaja, la más obvia, es que un paquete de hilos de nivel
usuariocpuede implementarse en un sistema operativo que no acepte hilos. Todos los sistemas
operativos solian entrar en esta categoría e implementaban los hilos por librerías.

Un problema con los paquetes de hilos de nivel usuario es que, si un hilo empieza a ejecutarse,
ningún otro hilo en ese proceso se ejecutará a menos que el primero renuncie de manera
voluntaria a la CPU. Dentro de un solo proceso no hay interrupciones de reloj, lo cual hace que sea
imposible planificar procesos en el formato round robin (tomando turnos). A menos que un hilo
entre al sistema en tiempo de ejecución por su propia voluntad, el planificador nunca tendrá una
oportunidad. Una posible solución al problema de los hilos que se ejecutan en forma indefinida es
hacer que el sistema en tiempo de ejecución solicite una señal de reloj (interrupción) una vez por
segundo para dar el control, pero esto también es crudo y complicado para un programa.
A nivel de kernel (kernel threads): Los hilos a nivel kernel son soportados y administrados
directamente por el SO. Hay tres maneras de establecer una relación de este tipo:

○ el modelo muchos a uno (many-to-one),

○ el modelo uno a uno (one-to-one) y

○ el modelo muchos a muchos (many-to-many).

Beneficios de los hilos en los sistemas operativos.

 Referente a Compartir Recursos. Estos se comunican unos con otros sin invocar al kernel,
debido a que los hilos dentro de un mismo proceso comparten memoria y archivos.
 Toma menos tiempo crear un nuevo hilo que un proceso.
 Es menor el tiempo para terminar un hilo que un proceso.
  Es menor el tiempo en conmutar entre dos hilos dentro del mismo proceso.
 Son utilizados en arquitecturas de multiprocesadores.

Uso de los hilos.

Cuando se utiliza un servidor web que da el servicio a varios usuarios; es capaz de procesar
solicitudes de acceso web simultáneamente, acá se está en presencia de una aplicación multi hilo.

Importante que los sistemas operativos consideran a los hilos (threads) aunque Linux no los llama
así, utiliza el término de tarea para referirse a un flujo de control dentro de un programa.

Si un hilo abre un archivo, ese archivo está visible para los demás hilos en el proceso y pueden
leer y escribir datos en él. Esto es lógico, ya que el proceso es la unidad de administración de
recursos, no el hilo. Si cada hilo tuviera su propio espacio de direcciones, archivos abiertos,
alarmas pendientes, etcétera, sería un proceso separado. Lo que estamos tratando de lograr con
el concepto de los hilos es la habilidad de que varios hilos de ejecución compartan un conjunto de
recursos, de manera que puedan trabajar en conjunto para realizar cierta tarea.

Estándares para hilos.

IEEE ha definido un estándar para los hilos conocido como 1003.1c. define una interfaz estándar
del sistema operativo y el entorno, incluyendo un intérprete de comandos. Se conoce como
POSIX (acrónimo de Portable Operating System Interface, y X viene de UNIX como seña de
identidad de la API.

Los siguientes Sistemas Operativos son 100% compatibles con uno o varios estándares
POSIX:

 A/UX
 AIX
 BSD/OS
 DSPnano
 HP-UX
 INTEGRITY
 IRIX
 LynxOS
 Mac OS X v10.5 en Procesadores Intel.
 MINIX
 MPE/iX
 QNX (IEEE Std. 1003.13-2003 PSE52;
 RTEMS (POSIX 1003.1-2003 Profile 52)
 Solaris
 Unison RTOS
 UnixWare
 velOSity
 VxWorks (IEEE Std. 1003.13-2003 PSE52;

Cygwin ofrece un desarrollo en gran parte compatible con POSIX y un entorno de ejecución para
Microsoft Windows.

Window Threads.

Es la unidad mínima de ejecución que Windows puede manejar, está asociada al proceso que la
creó, y está identificada por un número entero de 32 bits.

Un thread está compuesto por:

 Un número entero de 32 bits que la identifica unívocamente

 El estado de los registros del procesador
 Una pila (stack)
 Parámetros de seguridad (Session ID y Security Descriptor)
 Un valor de prioridad. La prioridad real de la thread es función de este valor y la prioridad del
proceso a que pertenece.
 Una entrada en la lista de ejecuciones de Windows
 Opcionalmente, una cola de mensajes

Cada thread tiene asociado un usuario (SID: Session ID) y unos parámetros de seguridad (SD
Security Descriptor), que determinan los permisos de la thread dentro del sistema operativo, y que
por defecto coinciden con los de la thread principal del proceso.

Una aplicación de Windows se ejecuta como un proceso separado y cada proceso puede contener
uno o más hilos. Además, Windows utiliza la asignación uno a uno donde a cada hilo a nivel de
usuario se le asigna un hilo del kernel.

Comunicación entre procesos.

Los hilos se pueden comunicar de muchas formas, incluyendo las tuberías, las tuberías con
nombre, las ranuras de correo, los sockets, las llamadas a procedimientos remotos y los archivos
compartidos. Las tuberías tienen dos modos: byte y mensaje; se selecciona uno de e llos al
momento de su creación. Las tuberías en modo de byte funcionan igual que en UNIX. Las tuberías
en modo de mensaje son algo similares, pero preservan los límites de los mensajes, de manera
que cuatro escrituras de 128 bytes se leerán como cuatro mensajes de 128 bytes y no como un
mensaje de 512 bytes, como podría ocurrir con las tuberías en modo de byte. También existen las
tuberías con nombre, y tienen los mismos dos modos que las regulares. Las tuberías con nombre
también se pueden utilizar a través de una red, pero las regulares no.

Las tuberías consisten en una cadena de procesos conectados de forma tal que la salida de cada
elemento de la cadena es la entrada del próximo. Permiten la comunicación y sincronización entre
procesos. Es común el uso de búfer de datos entre elementos consecutivos .

Las ranuras de correo son una característica del sistema operativo OS/2 que se implementó en
Windows por cuestión de compatibilidad. Son similares a las tuberías en ciertas formas, pero no
en todo. Por ejemplo, son de una vía, mientras que las tuberías son de dos vías. Se podrían utilizar
a través de una red, pero no pueden ofrecer una entrega garantizada. Por último, permiten que el
proceso emisor transmita un mensaje a muchos receptores, en vez de sólo uno. Tanto las ranuras
de correo como las tuberías con nombre se implementan como sistemas de archivos e n Windows,
en vez de implementarse como funciones del ejecutivo. De esta forma, se pueden utilizar a través
de la red mediante el uso de los protocolos existentes para sistemas de archivos remotos.

Los sockets son como las tuberías, excepto que por lo gene ral conectan procesos en distintas
máquinas. Por ejemplo, un proceso escribe en un socket y otro en una máquina remota lee la
información del primero. Los sockets también se pueden utilizar para conectar procesos en la
misma máquina, pero como generan más sobrecarga que las tuberías, por lo general se utilizan
sólo en un contexto de red. Los sockets se diseñaron originalmente para Berkeley UNIX, y la
implementación se hizo disponible en muchas partes.

Sincronización entre procesos.

Existen una serie de mecanismos de sincronización de procesos entre los que destacan:

Mutex: es un objeto que permite a los hilos asegurar la integridad de un recurso compartido al
que tienen acceso. Tiene dos estados: bloqueado y desbloqueado. Son una versión simplificada de
los semáforos.

Semáforos: son señales simples que pueden obligar a un proceso a detenerse en una posición
determinada. Ellos resuelven:

o Exclusión mutua: sólo uno de los procesos debe estar en la sección crítica en un instante
dado.
o Sincronización: un proceso debe esperar la ocurrencia de un evento para poder seguir
ejecutándose.

Monitor: es una colección de procedimientos, variables y estructuras de datos que se agrupan en

un tipo especial de módulo o paquete. Los procesos pueden llamar a los procedimientos en un
monitor cada vez que lo desean, pero no pueden acceder de manera directa a las estructuras de
datos internas del monitor desde procedimientos declarados fuera de éste.
Planificación de procesos.

Cuando una computadora se multiprograma, con frecuencia tiene varios procesos o hilos que
compiten por la CPU al mismo tiempo. Esta situación ocurre cada vez que dos o más de estos
procesos se encuentran al mismo tiempo en el estado listo. Si sólo hay un CPU disponible, hay que
decidir cuál proceso se va a ejecutar a continuación. La parte del sistema operativo que realiza
esa decisión se conoce como planificador de procesos y el algoritmo que utiliza se conoce como
algoritmo de planificación.

Aspectos teóricos a considerar.

Diferencia entre concurrencia y paralelismo.

Un sistema concurrente soporta más de una tarea al permitir que todas las tareas progresen.

Un sistema paralelo puede realizar más de una tarea simultáneamente.

Por lo tanto, es posible tener concurrencia sin paralelismo.

Antes de la llegada de las arquitecturas multiprocesador y multicore, la mayoría de los sistemas

informáticos tenían un solo procesador, y el planificador del CPU era diseñado para proporcionar
la ilusión de paralelismo al cambiar rápidamente entre procesos, permitiendo así que cada
proceso progrese, en este caso los procesos se ejecutaban concurrentemente, pero no en
paralelo.