Está en la página 1de 3

Solaris es un sistema operativo basado en UNIX creado por Sun Microsystems en 1992, diseado

como una mejora al sistema SunOS basado en el UNIX original que la misma compaa haba
diseado algunos aos atrs.

Procesos en Solaris:
El proceso es la abstraccin ms bsica y fundamental provista por un sistema operativo. Un
proceso es un objeto ejecutable que ocupa pginas de memoria fsica que contienen segmentos de
memoria especficos con instrucciones, espacio para stack, espacio para data, y otros componentes
necesarios para su ejecucin.
Solaris implementa una tabla de procesos, donde cada proceso es identificado de manera nica con
un nmero entero positivo llamado PID (Process Identification Number).
Solaris es un sistema operativo multi thread, es decir, las tareas llevadas a cabo por el sistema
operativo son ejecutadas como threads del kernel. Adicionalmente, Solaris mantiene dos conjuntos
de procesos, uno llamado el conjunto sesin del cual existe uno por usuario y agrupa a todos los
procesos que ha creado un usuario especfico, y el otro es llamado el conjunto de parentesco, en el
cual se mantiene la relacin de herencia entre procesos.
Estos procesos pueden tener uno o ms hilos de ejecucin a nivel de usuario, los cuales pueden ser
planificados independientemente el uno del otro por medio de un enlace uno a uno con un hilo de
ejecucin a nivel de kernel (a cada hilo de usuario le corresponde un hilo de kernel). Este enlace se
logra por medio de un objeto del sistema llamado proceso liviano (LWP por sus siglas en ingls), que
sirven para que el kernel del sistema est consciente de la existencia de los hilos de usuario Por lo
tanto, este sistema mantiene un conjunto de hilos de usuario, un conjunto de hilos de kernel y un
conjunto de LWP.
Figura de los procesos LWP

State of a Process:
A process undergoes many changes during its lifetime. For example, if a parent process waits for
the child process to complete execution, the parent process puts itself in sleep state. Such a
change from one state to another state is known as context switching. During its lifetime a process
can exist in any of these four states: Ready or Runnable, Running, Sleep, and Zombie. A runnable
process is ready to execute whenever CPU time is available. It has acquired all the resources it
needs and is just waiting for the CPU to become available. If the process is in the Run state, it
means that the process is running on the CPU. In the Sleep state, the process waits for a child
process to complete or waits for a resource to become available. Zombie is the phase in which the
child process terminates, but its entry is not removed from the process table until the parent
process acknowledges the death of the child process by executing wait() or waitpid() system call.
In this case, the child process is said to be in a Zombie state. Zombie processes are also called as
defunct processes.

Evolucin e implementacin de procesos e hilos en Solaris:


En las versiones ms antiguas de Solaris la relacin entre los hilos de usuario y los hilos de kernel
era de muchos a muchos (M x N), en donde los conjuntos no tenan que ser necesariamente
iguales y el SO era el encargado de designar como sera la funcin de relacin entre los conjuntos.
Actualmente, el modelo de hilos de Solaris se basa en una biblioteca llamada libthread.so, que fue
implementada dentro de este sistema a partir de Solaris 8. Esta biblioteca funcionaba
concurrentemente con los modelos de hilos de las versiones anteriores, pero fue establecida como
el modelo base de Solaris a partir de la versin 9. En la ltima versin, libthread.so fue integrada a
la biblioteca estndar de C incluida en Solaris para unificar el modelo de procesos de este SO.
Con respecto al modelo de hilos, ya se dijo que este pas de ser un modelo M x N a un modelo
uno a uno debido a problemas de diseo que aparecieron a lo largo de la vida de Solaris por
mltiples razones, entre ellas el avance de la tecnologa. Los problemas de diseo que se
plantearon son los siguientes:

En el modelo original, si un hilo de usuario no estaba enlazado a un LWP y se le mandaba


un mensaje, no se garantizaba que este llegara, precisamente debido a la falta de un LWP.
El planificador de hilos a nivel de usuario estaba implementado dentro de la biblioteca y el
kernel ocasionalmente poda no tener conocimiento de algunos hilos a nivel de usuario,
por el mismo problema de falta de un LWP, lo que provocaba que si el hilo de ejecucin
tuviera que ser planificado nuevamente, el proceso completo tambin deba hacerlo.
La tarea de mantener un conjunto de LWP lo suficientemente grande como para no
disminuir el rendimiento del sistema, por los problemas anteriores, era un trabajo muy
complejo que requera mucha atencin del SO.

Sistema de archivo de procesos:


Este sistema de archivo, llamado procfs, es un sistema de abstraccin provisto por Solaris para
simplificar la manipulacin de procesos y el anlisis de la informacin referente a estos. Cada
proceso de Solaris est representado como un directorio dentro de procfs, ubicado en el
subdirectorio proc del directorio raz. Cada directorio de proceso se identifica por su PID y
contiene archivos con informacin referente al proceso, y en el caso de los procesos multi-hilos, se
crea un subdirectorio por cada hilo, identificado por su lwp_id. Procfs usualmente se utiliza para
dos tareas del sistema. La primera es obtener informacin relacionada al proceso leyendo de los
archivos ubicados dentro del directorio. La segunda tarea es manipular el proceso representando
las operaciones realizables sobre ste, como si fueran operaciones de archivo, esto se realiza por
medio de directivas de control provistas por Solaris (ejemplo, la directiva prstat, que permite
visualizar informacin sobre el estado de procesos, utilizando procfs).

Planificador:
La unidad bsica de planificacin en Solaris es kthread_t. Solaris representa cada proceso como un
proc_t, y cada hebra dentro de un proceso tiene una kthread_t. Un proceso con una sola hebra en
Solaris tiene proc_t, una sola kthread_t, y una klwp_t. La estructura klwp_t proporciona un rea
de almacenamiento para el intercambio de hebras entre los modos de usuario y ncleo.
Las decisiones de planificacin estn basadas en la prioridad. En Solaris, a ms valor prioridad ms
alta
Solaris favorece los procesos/hebras interactivos. Las hebras interactivas se ejecutan con mejor
prioridad que las hebras con trabajos intensivos para la CPU, pero tienden a ejecutarse durante
franjas de tiempo ms pequeas.
Las hebras se planifican con prioridad desde la cola activa. Una hebra pasa de la cola activa a la
cola expirados cuando consume la franja de tiempo asignado (y posiblemente en otros momentos
para evitar la inanicin). Si una hebra consume su franja de tiempo, el ncleo le asigna una nueva
prioridad y la devuelve a la cola de envo. La cola de ejecucin almacena las hebras ejecutables en
diferentes listas enlazadas, una por prioridad.
Para obtener la prioridad de la hebra, Solaris realiza una bsqueda en una tabla. En lugar de
planificar n hebras, planifica, la prxima hebra a ejecutar.

También podría gustarte