Recordemos que un proceso se define por los recursos que usa y por el lugar don de se ejecuta.

Sin embargo, hay muchos casos en los que seria compartir los recursos y acceder a ellos de forma concurrente. Esta situaciOn es similar al caso en que se hace una llamada al sistema bifurcar (fork) con un nuevo contador de pro-grama, o hilo de control, ejecutandose dentro del mismo espacio de direcciones. Este concepto es tan titil que varios sistemas operativos nuevos incluyen un meca-nismo para apoyarlo mediante hilos.

4.5.1 Estructura de los hilos

Un hilo, tambien llamado proceso ligero (LWP, lightweight process), es una unidad bdsica de utilizacion de la CPU, y consiste en un contador de programa, un juego de registros y un espacio de pila. El hilo comparte con sus hilos pares la seccion de codigo, secci6n de datos y recursos del sistema operativo como archivos abiertos y senales, lo que se denomina colectivamente una tarea. Un proceso tradicional o pesado es igual a una tarea con un solo hilo. Una tarea no hace nada si no hay hilos en ella, y un hilo debe estar en una y solo una tarea. El extenso compartir hace que la conmutaciOn de la CPU entre h ilos pares, y la creacion de hilos, sea econornica en comparacion con las conmutaciones de contexto entre procesos pesados. Aunque una conmutaciOn de contexto de hilos tambien requiere un cambio de conjunto de registros, no hay que realizar operaciones relacionadas con la gestiOn de memoria. Al igual que cualquier entorno de procesamiento paralelo, el multihilado de un proceso puede introducir problemas de control de concurrencia que requieren el use de secciones crIticas o cerraduras. Ademas, algunos sistemas implementan hilos en el nivel de usuario en bibliotecas en el nivel de usuario, no por medio de llamadas al sistema, asi que la conmutadion de hilos no necesita invocar el sistema operativo ni causar una interrupcion para pasar al nude. La conmutacion entre hilos en el nivel de usuario puede hacerse con independencia del sistema operativo y, por tanto, muy rapidamente. Asi, blo quear un hilb y conmutar a otro es una soluciOn razonable al problema de coma un servidor puede manejar muchas solicitudes de forma eficiente. Los hilos en el nivel de usuario tienen desventajas. Por ejemplo, si el micleo es monohilado, cualquier hilo en el nivel de usuario que ejecute una llamada al sistema hard que toda la tarea espere hasta que la llamada regrese. Podemos captar la funcionalidad de los hilos si comparamos el control de multiples hilos con el control de multiples procesos. En el caso de los procesos, cada uno opera independientemente de los otros; cada proceso tiene su propio contador de -frograma, registro de pila y espacio de direcciones. Este tipo de organizacion es titil cuando los trabajos que los procesos efectdan no tienen relacion unos con otros. Otra posibilidad es que multiples procesos realicen la misma tarea. Por ejemplo, varios procesos podrfan suministrar datos a maquinas remotas en una implementaciOn de sistema de archivos de red. Sin embargo, es mas eficiente hacer que un proceso con multiples hilos se encargue de ello. En la implementacian con multiples procesos, cada uno ejecuta el mismo codigo pero tiene su propia memoria y recursos de archivos. Un proceso multihilado emplea menos recursos que varios procesos redundantes, incluida memoria, archivos abiertos y planificacion de CPU. Por ejemplo, a medida que Solaris evoluciona, se estan reescribiendo los demonios de red como hilos del micleo para aumentar considerablemente el desempeno de esas funciones de servidor de red. Los hilos operan, en muchos sentidos, de la misma forma que los procesos. Los hilos pueden estar en uno de varios estados: listo, bloqueado, en ejecucion o terminado. Al igual que los procesos, los hilos comparten la CPU, y solo hay un hilo activo (en ejecucion) en un instante dado. Un hilo dentro de un proceso se ejecuta secuencialmente, y cada hilo tiene su propia pila y contador de programa