Arquitectura dell So Windows NT

Indice1. Prólogo3. Diseño De Windows Nt4. Procesos5. Administracion De La Memoria6. Sistema De Archivos7. Entrada Y Salida8. Windows Nt 59. Bibliografia

1. Prólogo

El presente trabajo trata sobre la Arquitectura de Windows NT. La investigación se ha llevado a cabo desde cuatro puntos de vista que son los componentes señalados por Andrew Tanenbaum para el enfoque del estudio de un Sistema Operativo, es decir: procesos, administración de la memoria, ficheros y entrada/salida. Se ha comenzado con un capítulo dedicado a conceptos básicos y otro a la arquitectura global del sistema, para seguidamente estudiar en detalle cada uno de los cuatro puntos antes citados.

Se puede decir que Windows NT representa la primera propuesta de la empresa Microsoft por construir un Sistema Operativo serio, capaz de competir con los dinosaurios clásicos como UNIX o VMS (o al menos intentarlo). Para ello se ha elegido un enfoque cliente–servidor, con la intención de alcanzar el sueño de los Sistemas Distribuidos.

Windows NT no se puede considerar todavía un sistema operativo de carácter doméstico. Pero el objetivo de sus diseñadores parece ser que lo sea dentro de muy pocos años, y de hecho, para que los programadores vayan entreteniéndose en el uso de las llamadas al sistema (el llamado Win32), han construido un Sistema Operativo de poco confiable. Hablamos, cómo no, de Windows 95.

La arquitectura de Windows 95/98 no tiene absolutamente nada que ver con la de Windows NT. No es que sea un mal trabajo pero deja bastante que desear.

Durante la elaboración de este trabajo nos hemos encontrado con varias dificultades principalmente por la falta de fuentes bibliográficas que trataran el diseño con la suficiente profundidad como para satisfacer el nivel que se buscaba. Los libros que se encontraron, la mayoría se refieren a la Administración del Sistema a alto nivel, o bien de la programación bajo Windows NT en lenguaje C++, por lo que he tenido que recurrir a diversos artículos de la Internet, principalmente al nodo de Microsoft en Internet. Por ello, pedimos disculpas por las posibles erratas que puedan existir.

Para tratar ciertos temas dentro de cada capítulo se ha creído conveniente apoyarnos en la descripción de las llamadas al sistema, ya que, a nuestro entender, de esta manera todo resulta mucho más fácil de explicar y de comprender.

2. Introduccion Y Conceptos Basicos

Eventos A Través Del Tiempo

A finales de los años 40's y a principios de los años 50's las computadoras masivas, eran controladas por tubos al vacío inestables. Todo la programación se hacía directamente en lenguaje de máquina porque la industria no había avanzado lo suficiente para necesitar Sistemas Operativos. Con la aparición del transistor a mediados de los 50's, las computadoras se fueron haciendo más y más confiables.

Lenguajes crudos como Ensamblador y Fortran aparecieron, pero un Sistema Operativo (S.O.), tal como los conocemos ahora, aún no. Para accesar a la programación de la maquinaria se manejaron tarjetas perforadas.

1960's. Cuando IBM introdujo la computadora System/360 intentó tomar el mercado científico y el comercial. Cuando en este proyecto surgieron problemas de conflictos por la arquitectura, se inició el desarrollo de un software que resolviera todos aquellos conflictos, el resultado fue un muy complejo sistema operativo. Luego AT&T trató de desarrollar a Multics, un Sistema Operativo que soportara cientos de usuarios de tiempo compartido, pero falló. Más adelante científicos de la computación desarrollaron Unics, que sería monousuario. Ello marca el nacimiento de Unix (1969), el primero de los sistemas operativos modernos.

1980's. En este tiempo la arquitectura de las computadoras, circuitos LSI (Large Scale Integration) abrieron el paso para una nueva generación de computadoras. DOS de Microsoft aparece en 1981 dominando este mercado de las PCs inmediatamente, aunque el sistema UNIX, predomina en las estaciones de trabajo.

1990's. Aumenta el uso de conexiones en redes, equipos de trabajo y aplicaciones distribuidas, los cuales surgen en la década anterior, con ello los Sistemas Operativos como Unix, Windows NT, etc., soportan muchos clientes, dando así el nacimiento de la Computación en Red.

Sistema Operativo

Introducción

Software básico que controla y administra los recursos de una computadora. El sistema operativo tiene tres grandes funciones: coordina y manipula el hardware de la computadora, como la memoria, las impresoras, las unidades de disco, el teclado o el mouse; organiza los archivos en diversos dispositivos de almacenamiento, como discos flexibles, discos duros, discos compactos o cintas magnéticas, y gestiona los errores de hardware y la pérdida de datos.

¿Cómo funciona un sistema operativo?

Los Sistemas Operativos controlan diferentes procesos de la computadora. Un proceso importante es la interpretación de los comandos que permiten al usuario comunicarse con el ordenador. Algunos intérpretes de instrucciones están basados en texto y exigen que las instrucciones sean tecleadas. Otros están basados en gráficos, y permiten al usuario comunicarse señalando y haciendo clic en un icono.

Los Sistemas Operativos pueden ser de tarea única o multitarea. Los sistemas operativos de tarea única, más primitivos, sólo pueden manejar un proceso en cada momento. Por ejemplo, cuando la computadora está imprimiendo un documento, no puede iniciar otro proceso ni responder a nuevas instrucciones hasta que se termine la impresión.

Todos los Sistemas Operativos modernos son multitarea y pueden ejecutar varios procesos simultáneamente. En la mayoría de los ordenadores sólo hay una UCP; un Sistema Operativo multitarea crea la ilusión de que varios procesos se ejecutan simultáneamente en la UCP. El mecanismo que se emplea más a menudo para lograr esta ilusión es la multitarea por segmentación de tiempos, en la que cada proceso se ejecuta individualmente durante un periodo de tiempo determinado. Si el proceso no finaliza en el tiempo asignado, se suspende y se ejecuta otro proceso. Este intercambio de procesos se denomina conmutación de contexto. El sistema operativo se encarga de controlar el estado de los procesos suspendidos. También cuenta con un mecanismo llamado planificador que determina el siguiente proceso que debe ejecutarse. El planificador ejecuta los procesos basándose en su prioridad para minimizar el retraso percibido por el usuario. Los procesos parecen efectuarse simultáneamente por la alta velocidad del cambio de contexto.

Los Sistemas Operativos pueden emplear memoria virtual para ejecutar procesos que exigen más memoria principal de la realmente disponible. Con esta técnica se emplea espacio en el disco duro para simular la memoria adicional necesaria.

Sistemas Operativos actuales

Los sistemas operativos empleados normalmente son UNIX, Macintosh OS, MS-DOS, OS/2 y Windows-NT. El UNIX y sus clones permiten múltiples tareas y múltiples usuarios. Su sistema de archivos proporciona un método sencillo de organizar archivos y permite la protección de archivos. Sin embargo, las instrucciones del UNIX no son intuitivas. Otros sistemas operativos multiusuario y multitarea son OS/2, desarrollado inicialmente por Microsoft Corporation e International Business Machines (IBM) y Windows-NT, desarrollado por Microsoft. El sistema operativo multitarea de las computadoras Apple se denomina Macintosh OS. El DOS y su sucesor, el MS-DOS, son sistemas operativos populares entre los usuarios de computadoras personales. Sólo permiten un usuario y una tarea.

Sistema Operativo de Red

A un Sistema Operativo de Red se le conoce como NOS. Es el software necesario para integrar los muchos componentes de una red en un sistema particular, al cual el usuario final puede tener acceso.

Otra definición es la siguiente; es un software que rige y administra los recursos, archivos, periféricos, usuarios, etc., en una red y lleva el control de seguridad de los mismos.

Un NOS maneja los servicios necesarios para asegurar que el usuario final tenga o esté libre de error al accesar a la red. Un NOS normalmente provee una interfaz de usuario que es para reducir la complejidad y conflictos al momento de usar la red.

Dentro del contexto del Sistema Operativo de Red, se pueden escribir aplicaciones tales como un sistema de correo electrónico pueden ser escritas para que permitan "conexiones virtuales" entre entidades de red, sin intervención humana directa.

Diferencia entre un S.O. Distribuido, un S.O. de Red y un S.O. Centralizado.

En un Sistema Operativo de Red, los usuarios saben de la existencia de varias computadoras y pueden conectarse con máquinas remotas y copiar archivos de una máquina a otra, cada máquina ejecuta su propio sistema operativo local y tiene su propio usuario o grupo de usuarios.

Por el contrario, un Sistema Operativo Distribuido es aquel que aparece ante sus usuarios como un sistema tradicional de un solo procesador, aun cuando esté compuesto por varios procesadores. En un sistema distribuido verd adero, los usuarios no deben saber del lugar donde su programa se ejecute o del lugar donde se encuentran sus archivos; eso debe ser manejado en forma automática y eficaz por el Sistema Operativo.

Además son sistemas autónomos capaces de comunicarse y cooperar entre sí para resolver tareas globales. Es indispensable el uso de redes para intercambiar datos. Además de los servicios típicos de un Sistema Operativo, un Sistema Distribuido debe gestionar la distribución de tareas entre los diferentes nodos conectados. También, debe proporcionar los mecanismos necesarios para compartir globalmente los recursos del sistema.

Sistemas Operativos Centralizados, de un solo procesador, de un solo CPU o incluso tradicionales; en todo caso, lo que esto quiere decir es que un sistema operativo controla una sola computadora.

3. Diseño De Windows Nt

Windows NT presenta una arquitectura del tipo cliente-servidor. Los programas de aplicación son contemplados por el sistema operativo como si fueran clientes a los que hay que servir, y para lo cual viene equipado con distintas entidades servidoras.

Uno de los objetivos fundamentales de diseño fue el tener un núcleo tan pequeño como fuera posible, en el que estuvieran integrados módulos que dieran respuesta a aquellas llamadas al sistema que necesariamente se tuvieran que ejecutar en modo privilegiado (también llamado modo kernel, modo núcleo y modo supervisor). El resto de las llamadas se expulsarían del núcleo hacia otras entidades que se ejecutarían en modo no privilegiado (modo usuario), y de esta manera el núcleo resultaría una base compacta, robusta y estable. Por eso se dice que Windows NT es un sistema operativo basado en micro-kernel.

Es por ello que en un primer acercamiento a la arquitectura distinguimos un núcleo que se ejecuta en modo privilegiado, y se denomina Executive, y unos módulos que se ejecutan en modo no privilegiado, llamados subsistemas protegidos.

Los programas de usuario (también llamados programas de aplicación) interaccionan con cualquier sistema operativo (SO) a través de un juego de llamadas al sistema, que es particular de cada SO. En el mundo Windows en general, las llamadas al sistema se denominan API (Application Programming Interfaces, interfaces para la programación de aplicaciones). En Windows NT y en Windows 95 se usa una versión del API llamada API Win32. Un programa escrito para Windows NT o Windows 95, y que por consiguiente hace uso del API Win32, se denomina genéricamente "programa Win32", y de hecho esta denominación es bastante frecuente en artículos y libros al respecto. Desgraciadamente, y conviene dejarlo claro cuanto antes, el término "Win32" tiene tres acepciones (al menos hasta ahora) totalmente distintas. Una es el API, otra es el nombre de uno de los subsistemas protegidos de Windows NT del que hablaremos más adelante, y por último se denomina Win32s a una plataforma desarrollada por Microsoft, similar a Windows 3.1, pero que usa el API Win32 en vez del API Win16 del Windows 3.1.

Hechas estas aclaraciones, podemos continuar adelante. Algunas de las llamadas al sistema, debido a su naturaleza, son atendidas directamente por el Executive, mientras que otras son desviadas hacia algún subsistema. Esto lo veremos con detalle en breve.

El hecho de disponer de un núcleo rodeado de subsistemas que se ejecutan en modo usuario nos permite además añadir nuevos subsistemas sin producir ningún tipo de confrontación.

En el diseño de Windows NT han confluido aportaciones de tres modelos: el modelo cliente-servidor, el modelo de objetos, y el modelo de multiprocesamiento simétrico.

Modelo cliente-servidor. En la teoría de este modelo se establece un kernel que básicamente se encarga de recibir peticiones de procesos clientes y pasárselas a otros procesos servidores, ambos clientes y servidores ejecutándose en modo usuario. Windows NT pone el modelo en práctica pero no contempla el núcleo como un mero transportador de mensajes, sino que introduce en él aquellos servicios que sólo pueden ser ejecutados en modo kernel. El resto de servicios los asciende hacia subsistemas servidores que se ejecutan en modo usuario, independientes entre sí, y que por tanto pueden repartirse entre máquinas distintas, dando así soporte a un sistema distribuido (de hecho, el soportar los sistemas distribuidos fue otra de las grandes directivas de diseño de este SO).

Modelo de objetos. Decir que no implementa puramente la teoría de este modelo, sino que más bien lo que hace es simplemente contemplar los recursos (tanto internos como externos) como objetos. Más adelante daremos una lista de los objetos de Windows NT. Brevemente, señalar que todo objeto ha de poseer identidad propia (es único y distinguible de todos los demás), y una serie de atributos (variables) y métodos (funciones) que modifican sus atributos. Los objetos interaccionan entre sí a través del envío de mensajes. No sólo existen en Windows NT objetos software (lógicos), sino que los dispositivos hardware (físicos) también son tratados como objetos (a diferencia de UNIX, que recordemos trataba a los dispositivos como ficheros).

Modelo de multiprocesamiento simétrico. Un SO multiproceso (o sea, aquel que cuenta con varias CPU y cada una puede estar ejecutando un proceso) puede ser simétrico (SMP) o asimétrico (ASMP). En los sistemas operativos SMP (entre los que se encuentran Windows NT y muchas versiones de UNIX) cualquier CPU puede ejecutar cualquier proceso, ya sea del SO o no, mientras que en los ASMP se elige una CPU para uso exclusivo del SO y el resto de CPU quedan para ejecutar programas de usuario. Los sistemas SMP son más complejos que los ASMP, contemplan un mejor balance de la carga y son más tolerantes a fallos (de manera que si un subproceso del SO falla, el SO no se caerá pues podrá ejecutarse sobre otra CPU, cosa que en los ASMP no sería posible, con lo que se bloquearía el sistema entero).

Comencemos describiendo los subsistemas protegidos, para seguidamente estudiar la estructura del Executive.

Figura 1. El núcleo se ejecuta en modo privilegiado (Executive) y en modo no privilegiado (subsistemas protegidos)

Los Subsistemas Protegidos

Son una serie de procesos servidores que se ejecutan en modo usuario como cualquier proceso de usuario, pero que tienen algunas características propias que los hacen distintos. Al decir subsistemas protegidos nos referiremos, pues, a estos procesos. Se inician al arrancar el SO. Los hay de dos tipos: integrales y de entorno.

Un Subsistema Integral: es aquel servidor que ejecuta una función crítica del SO (como por ejemplo el que gestiona la seguridad). Tenemos los siguientes:

El Subsistema Proceso de Inicio (Logon Process)

El proceso de inicio (Logon Process) recibe las peticiones de conexión por parte de los usuarios. En realidad son dos procesos, cada uno encargándose de un tipo distinto de conexión:

El proceso de inicio local: gestiona la conexión de usuarios locales directamente a una máquina Windows NT.

El proceso de inicio remoto: gestiona la conexión de usuarios remotos a procesos servidores de Windows NT.

Figura 2. Diagrama de Flujo del Proceso de Inicio de Windows NT.

El Subsistema de Seguridad

Este subsistema interacciona con el proceso de inicio y el llamado monitor de referencias de seguridad (se tratara en el Executive), y de esta forma se construye el modelo de seguridad en Windows NT.

El subsistema de seguridad interacciona con el proceso de inicio, atendiendo las peticiones de acceso al sistema. Consta de dos subcomponentes:

La autoridad de seguridad local: es el corazón del subsistema. En general gestiona la política de seguridad local; así, se encarga de generar los permisos de acceso, de comprobar que el usuario que solicita conexión tiene acceso al sistema, de verificar todos los accesos sobre los objetos (para lo cual se ayuda del monitor de referencias a seguridad) y de controlar la política de auditorías, llevando la cuenta de los mensajes de auditoría generados por el monitor de referencias. Las auditorías son una facilidad que proporciona Windows NT para monitorizar diversos acontecimientos del sistema por parte del Administrador.

El administrador de cuentas: mantiene una base de datos con las cuentas de todos los usuarios (login, claves, identificaciones, etc.). Proporciona los servicios de validación de usuarios requeridos por el subcomponente anterior.

Un Subsistema de Entorno: da soporte a aplicaciones procedentes de SO distintos, adaptándolas para su ejecución bajo Windows NT. Existen tres de este tipo:

El Subsistema Win32

Es el más importante, ya que atiende no sólo a las aplicaciones nativas de Windows NT, sino que para aquellos programas no Win32, reconoce su tipo y los lanza hacia el subsistema correspondiente. En el caso de que la aplicación sea MS-DOS o Windows de 16 bits (Windows 3.11 e inferiores), lo que hace es crear un nuevo subsistema protegido pero no servidor. Así, la aplicación DOS o Win16 se ejecutaría en el contexto de un proceso llamado VDM (Virtual DOS Machine, máquina virtual DOS), que no es más que un simulador de un ordenador funcionando bajo MS-DOS. Las llamadas al API Win16 serían correspondidas con las homónimas en API Win32. Microsoft llama a esto WOW (Windows On Win32).

El subsistema soporta una buena parte del API Win32. Así, se encarga de todo lo relacionado con la interfaz gráfica con el usuario (GUI), controlando las entradas del usuario y salidas de la aplicación. Por ejemplo, un buen número de funciones de las bibliotecas USER32 y GDI32 son atendidas por Win32, ayudándose del Executive cuando es necesario.

El funcionamiento como servidor de Win32 lo veremos un poco más adelante, en el apartado de llamadas a procedimientos locales.

El Subsistema POSIX

La norma POSIX (Portable Operating System Interface for Unix) fue elaborada por IEEE para conseguir la portabilidad de las aplicaciones entre distintos entornos UNIX. La norma se ha implementado no sólo en muchas versiones de UNIX, sino también en otros SO como Windows NT, VMS, etc. Se trata de un conjunto de 23 normas, identificadas como IEEE 1003.0 a IEEE 1003.22, o también POSIX.0 a POSIX.22, de las cuales el subsistema POSIX soporta la POSIX.1, que define un conjunto de llamadas al sistema en lenguaje C.

El subsistema sirve las llamadas interaccionando con el Executive. Se encarga también de definir aspectos específicos del SO UNIX, como pueden ser las relaciones jerárquicas entre procesos padres e hijos (las cuales no existen en el subsistema Win32, por ejemplo, y que por consiguiente no aparecen implementadas directamente en el Executive).

El Subsistema OS/2

Igual que el subsistema POSIX proporciona un entorno para aplicaciones UNIX, este subsistema da soporte a las aplicaciones OS/2. Proporciona la interfaz gráfica y las llamadas al sistema; las llamadas son servidas con ayuda del Executive.

El Executive

No se debe confundir el Executive con el núcleo de Windows NT, aunque muchas veces se usan (incorrectamente) como sinónimos. El Executive consta de una serie de componentes software, que se ejecutan en modo privilegiado, y uno de los cuales es el núcleo. Dichos componentes son totalmente independientes entre sí, y se comunican a través de interfaces bien definidas. Recordemos que en el diseño se procuró dejar el núcleo tan pequeño como fuera posible, y, como veremos, la funcionalidad del núcleo es mínima. Pasemos a comentar cada módulo.

El Administrador de Objetos (Object Manager)

Se encarga de crear, destruir y gestionar todos los objetos del Executive. Tenemos infinidad de objetos: procesos, subprocesos, ficheros, segmentos de memoria compartida, semáforos, mutex, sucesos, etc. Los subsistemas de entorno (Win32, OS/2 y POSIX) también tienen sus propios objetos. Por ejemplo, un objeto ventana es creado (con ayuda del administrador de objetos) y gestionado por el subsistema Win32. La razón de no incluir la gestión de ese objeto en el Executive es que una ventana sólo es innata de las aplicaciones Windows, y no de las aplicaciones UNIX o OS/2. Por tanto, el Executive no se encarga de administrar los objetos relacionados con el entorno de cada SO concreto, sino de los objetos comunes a los tres.

El Administrador de Procesos (Process Manager)

Se encarga (en colaboración con el administrador e objetos) de crear, destruir y gestionar los procesos y subprocesos. Una de sus funciones es la de repartir el tiempo de CPU entre los distintos subprocesos (ver el capítulo de los procesos). Suministra sólo las relaciones más básicas entre procesos y subprocesos, dejando el resto de las interrelaciones entre ellos a cada subsistema protegido concreto. Por ejemplo, en el entorno POSIX existe una relación filial entre los procesos que no existe en Win32, de manera que se constituye una jerarquía de procesos. Como esto sólo es específico de ese subsistema, el administrador de objetos no se entromete en ese trabajo y lo deja en manos del subsistema.

El Administrador de Memoria Virtual (Virtual Memory Manager)

Windows NT y UNIX implementan un direccionamiento lineal de 32 bits y memoria virtual paginada bajo demanda. El VMM se encarga de todo lo relacionado con la política de gestión de la memoria: determina los conjuntos de trabajo de cada proceso, mantiene un conjunto de páginas libres, elige páginas víctima, sube y baja páginas entre la memoria RAM y el archivo de intercambio en disco, etc. Una explicación detallada la dejaremos para el capítulo de la memoria.

Facilidad de Llamada a Procedimiento Local (LPC Facility)

Este módulo se encarga de recibir y envíar las llamadas a procedimiento local entre las aplicaciones cliente y los subsistemas servidores.

Administrador de Entrada/Salida (I/O Manager)

Consiste en una serie de subcomponentes, que son:

El administrador del sistema de ficheros

El servidor y el redirector de red

Los drivers de dispositivo del sistema

El administrador de caches

Buena parte de su trabajo es la gestión de la comunicación entre los distintos drivers de dispositivo, para lo cual implementa una interfaz bien definida que permite el tratamiento de todos los drivers de una manera homogénea, sin que intervenga el cómo funciona específicamente cada uno.

Trabaja en conjunción con otros componentes del Executive, sobre todo con el VMM. Le proporciona la E/S síncrona y asíncrona, la E/S a archivos asignados en memoria y las caches de los ficheros.

El administrador de caches no se limita a gestionar unos cuantos buffers de tamaño fijo para cada fichero abierto, sino que es capaz de estudiar las estadísticas sobre la carga del sistema y variar dinámicamente esos tamaños de acuerdo con la carga. El VMM realiza algo parecido en su trabajo, como veremos en su momento.

Este componente da soporte en modo privilegiado al subsistema de seguridad, con el que interacciona. Su misión es actuar de alguna manera como supervisor de accesos, ya que comprueba si un proceso determinado tiene permisos para acceder a un objeto determinado, y monitoriza sus acciones sobre dicho objeto.

De esta manera es capaz de generar los mensajes de auditorías. Soporta las validaciones de acceso que realiza el subsistema de seguridad local.

En UNIX, de la seguridad se encargaba un módulo llamado el Kerberos (Cancerbero), desarrollado por el MIT como parte del Proyecto Atenas. Kerberos se ha convertido en una norma de facto, y se incorporará a Windows NT en su versión 5.0.

El Núcleo (Kernel)

Situado en el corazón de Windows NT, se trata de un micro-kernel que se encarga de las funciones más básicas de todo el SO:

Ejecución de subprocesos

Sincronización multiprocesador

Manejo de las interrupciones hardware

Nivel de Abstracción de Hardware (HAL)

Es una capa de software incluida en el Executive que sirve de interfaz entre los distintos drivers de dispositivo y el resto del sistema operativo. Con HAL, los dispositivos se presentan al SO como un conjunto homogéneo, a través de un conjunto de funciones bien definidas. Estas funciones son llamadas tanto desde el SO como desde los propios drivers. Permite a los drivers de dispositivo adaptarse a distintas arquitecturas de E/S sin tener que ser modificados en gran medida. Además oculta los detalles hardware que conlleva el multiprocesamiento simétrico de los niveles superiores del SO.

Llamadas a Procedimientos Locales y Remotos

Windows NT, al tener una arquitectura cliente-servidor, implementa el mecanismo de llamada a procedimiento remoto (RPC) como medio de comunicación entre procesos clientes y servidores, situados ambos en máquinas distintas de la misma red. Para clientes y servidores dentro de la misma máquina, la RPC toma la forma de llamada a procedimiento local (LPC). Vamos a estudiar en detalle ambos mecanismos pues constituyen un aspecto fundamental del diseño de Windows NT.

RPC (Remote Procedure Call)

Se puede decir que el sueño de los diseñadores de Windows NT es que algún día se convierta en un sistema distribuido puro, es decir, que cualquiera de sus componentes pueda residir en máquinas distintas, siendo el kernel en cada máquina el coordinador general de mensajes entre los distintos componentes. En la última versión de Windows NT esto no es aún posible.

No obstante, el mecanismo de RPC permite a un proceso cliente acceder a una función situada en el espacio virtual de direcciones de otro proceso servidor situado en otra máquina de una manera totalmente transparente.

Vamos a explicar el proceso en conjunto. Supongamos que se tiene un proceso cliente ejecutándose bajo una máquina A, y un proceso servidor bajo una máquina B. El cliente llama a una función f de una biblioteca determinada. El código de f en su biblioteca es una versión especial del código real; el código real reside en el espacio de direcciones del servidor. Esa versión especial de la función f que posee el cliente se denomina proxy. El código proxy lo único que hace es recoger los parámetros de la llamada a f, construye con ellos un mensaje, y pasa dicho mensaje al Executive. El Executive analiza el mensaje, determina que va destinado a la máquina B, y se lo envía a través del interfaz de transporte. El Executive de la máquina B recibe el mensaje, determina a qué servidor va dirigido, y llama a un código especial de dicho servidor, denominado stub, al cual le pasa el mensaje. El stub desempaqueta el mensaje y llama a la función f con los parámetros adecuados, ya en el contexto del proceso servidor. Cuando f retorna, devuelve el control al código stub, que empaqueta todos los parámetros de salida (si los hay), forma así un mensaje y se lo pasa al Executive.

Ahora se repite el proceso inverso; el Executive de B envía el mensaje al Executive de A, y este reenvía el mensaje al proxy. El proxy desempaqueta el mensaje y devuelve al cliente los parámetros de retorno de f. Por tanto, para el cliente todo el mecanismo ha sido transparente. Ha hecho una llamada a f, y ha obtenido unos resultados; ni siquiera tiene que saber si el código real de f está en su biblioteca o se encuentra en una máquina situada tres plantas más abajo.

LPC (Local Procedure Call)

Las LPC se pueden considerar una versión descafeinada de las RPC. Se usan cuando un proceso necesita los servicios de algún subsistema protegido, típicamente Win32. Se intentara descubrir su funcionamiento.

El proceso cliente tiene un espacio virtual de 4 Gb. Los 2 Gb inferiores son para su uso (excepto 128 Kb). Los 2 Gb superiores son para uso del sistema.

Vamos a suponer que el cliente realiza una llamada a la función CreateWindow. Dicha función crea un objeto ventana y devuelve un descriptor al mismo. No es gestionada directamente por el Executive, sino por el subsistema Win32 (con algo de colaboración por parte del Executive, por supuesto; por ejemplo, para crear el objeto). El subsistema Win32 va guardando en su propio espacio de direcciones una lista con todos los objetos ventana que le van pidiendo los procesos. Por consiguiente, los procesos no tienen acceso a la memoria donde están los objetos; simplemente obtienen un descriptor para trabajar con ellos. Cuando el cliente llama a CreateWindow, se salta al código de esa función que reside en la biblioteca USER32.DLL asignada en el espacio de direcciones del cliente.

Por supuesto, ese no es el código real, sino el proxy. El proxy empaqueta los parámetros de la llamada, los coloca en una zona de memoria compartida entre el cliente y Win32, pone al cliente a dormir y ejecuta una LPC. La facilidad de llamada a procedimiento local del Executive captura esa llamada, y en el subsistema Win32 se crea un subproceso que va a atender a la petición del cliente. Ese subproceso es entonces despertado, y comienza a ejecutar el correspondiente código de stub. Los códigos de stub de los subsistemas se encuentran en los 2 Gb superiores (los reservados) del espacio virtual del proceso cliente. Aunque no he encontrado más documentación al respecto, es muy probable que dichos 2 Gb sean los mismos que se ven desde el espacio virtual de Win32. Sea como sea, el caso es que el stub correspondiente desempaqueta los parámetros del área de memoria compartida y se los pasa a la función CreateWindow situada en el espacio de Win32. Ése sí es el código real de la función. Cuando la función retorna, el stub continúa, coloca el descriptor a la ventana en la memoria compartida, y devuelve el control de la LPC al Executive. El subproceso del Win32 es puesto a dormir. El Executive despierta al subproceso cliente, que estaba ejecutando código proxy. El resto de ese código lo que hace es simplemente tomar el descriptor y devolverlo como resultado de la función CreateWindow.

4. Procesos

Definición de Proceso y Sub Proceso

Debemos tener cuidado con no confundir el proceso en Windows NT con el proceso en los SO más clásicos, como UNIX. Vamos a intentar dar una definición general de lo que entiende Windows NT por proceso y subproceso, aunque después iremos perfilando poco a poco ambos conceptos.

Un proceso es una entidad no ejecutable que posee un espacio de direcciones propio y aislado, una serie de recursos y una serie de subprocesos. En el espacio de direcciones hay colocado algún código ejecutable (entre otras cosas). Bien, hemos dicho que un proceso es una entidad "no-ejecutable". En efecto, no puede ejecutar el código de su propio espacio de direcciones, sino que para esto le hace falta al menos un subproceso. Por consiguiente, un subproceso es la unidad de ejecución de código. Un subproceso está asociado con una serie de instrucciones, unos registros, una pila y una cola de entrada de mensajes (enviados por otros procesos o por el SO).

Cuando se crea un proceso, automáticamente se crea un subproceso asociado (llamado subproceso primario). Los subprocesos también se llaman "hebras de ejecución" (threads of execution). Debe quedarnos muy claro, pues, que lo que se ejecutan son subprocesos, no procesos. Los procesos son como el soporte sobre el que corren los subprocesos. Y entre los subprocesos se reparte el tiempo de CPU.

Podemos pensar en los subprocesos de Windows NT como los procesos de los SO clásicos (aunque existen matices, como sabemos). A veces, por comodidad y por costumbre, usaremos ambos términos como sinónimos, y diremos que "el proceso A llama a CreateWindow", aunque se debe entender que "un subproceso del proceso A llama a CreateWindow".

Un proceso tiene un espacio de direcciones virtuales de 4 Gb. En algún lugar de ese espacio se halla un código ejecutable (que quizás es la imagen de un programa en disco). Un proceso puede crear subprocesos, estando su número fijado por el sistema. Se dice que muere cuando todos sus subprocesos han muerto (incluso aunque el subproceso primario haya muerto, si aún existe algún subproceso propiedad del proceso, el proceso seguirá vivo).

Planificación del Tiempo de la CPU por Round Robin con Prioridades

Windows NT utiliza la planificación del anillo circular o round robin. Esta técnica consiste en que los subprocesos que pueden ser ejecutados se organizan formando un anillo, y la CPU va dedicándose a cada uno durante un tiempo. El tiempo máximo que la CPU va a estar dedicada a cada uno se denomina quantum, y es fijado por el Administrador del Sistema.

Si el subproceso está esperando por alguna entrada-salida o por algún suceso, la CPU lo pondrá a dormir, y pondrá en ejecución al siguiente del anillo. Si un subproceso que la CPU está ejecutando consume su quantum, la CPU también lo pondrá a dormir, pasando al siguiente.

En Windows NT, existe un rango de prioridades que va del 1 al 31, siendo 31 la más alta. Todo proceso y subproceso tienen un valor de prioridad asociado.

Existe un anillo o cola circular por cada uno de los niveles de prioridad. En cada anillo están los subprocesos de la misma prioridad. El Executive comienza a repartir el tiempo de CPU en el primer anillo de mayor prioridad no vacío. A cada uno de esos subprocesos se les asigna secuencialmente la CPU durante el tiempo de un quantum, como ya indicamos antes. Cuando todos los subprocesos de nivel de prioridad n están dormidos, el Executive comienza a ejecutar los del nivel (n-1), siguiendo el mismo mecanismo.

Análogamente, si un subproceso se está ejecutando, y llegara uno nuevo de prioridad superior, el Executive suspendería al primero (aunque no haya agotado su quantum), y comenzaría a ejecutar el segundo (asignándole un quantum completo).

Prioridad de proceso y subproceso

Un proceso se dice que pertenece a una clase de prioridad. Existen cuatro clases de prioridad, que son:

Desocupado. Corresponde a un valor de prioridad 4.

Normal. Corresponde a un valor de prioridad 7 ó 9.

Alta. Corresponde a un valor de prioridad 13.

Tiempo Real. Corresponde a un valor de prioridad 24.

La clase "Normal" es la que el Executive asocia a los procesos por defecto. Los procesos en esta clase se dice que tienen una prioridad dinámica: el Executive les asigna un valor de 7 si se están ejecutando en segundo plano, mientras que si pasan a primer plano, la prioridad se les aumenta a un valor de 9.

La clase "Desocupado" va bien para procesos que se ejecuten periódicamente y que por ejemplo realicen alguna función de monitorización.

La clase "Alta" la tienen procesos tales como el Administrador de Tareas (Task Manager). Dicho proceso está la mayor parte del tiempo durmiendo, y sólo se activa si el usuario pulsa Control-Esc. Entonces, el SO inmediatamente pone a dormir al subproceso en ejecución (aunque no haya agotado su quantum) y ejecuta al subproceso correspondiente del proceso Administrador de Tareas, que visualizará el cuadro de diálogo característico, mostrándonos las tareas actuales.

La clase "Tiempo Real" no es recomendable que la tenga ningún proceso normal. Es una prioridad más alta incluso que muchos procesos del sistema, como los que controlan el ratón, el teclado, el almacenamiento en disco en segundo plano, etc. Es evidente que usar esta prioridad sin un control extremo puede causar consecuencias nefastas.

Así como un proceso tiene una prioridad oscilando entre cuatro clases, un subproceso puede tener cualquier valor en el rango [1,31]. En principio, cuando el subproceso es creado, su prioridad es la correspondiente a la de la clase de su proceso padre. Pero este valor puede ser modificado si el subproceso llama a la función

BOOL SetThreadPriority (HANDLE hThread, int nPriority);

Donde:

hThread es el descriptor del subproceso

nPriority puede ser:

THREAD_PRIORITY_LOWEST : resta 2 a la prioridad del padre

THREAD_PRIORITY_BELOW_NORMAL: resta 1 a la prioridad del padre

THREAD_PRIORITY_NORMAL: mantiene la prioridad del padre

THREAD_PRIORITY_ABOVE_NORMAL: suma 1 a la prioridad del padre

THREAD_PRIORITY_HIGHEST: suma 2 a la prioridad del padre

THREAD_PRIORITY_IDLE: hace la prioridad igual a 1, independientemente de la prioridad del padre

THREAD_PRIORITY_TIME_CRITICAL: hace la prioridad igual a 15 si la clase de prioridad del padre es desocupada, normal o alta; si es tiempo real, entonces hace la prioridad igual a 31

De esta manera es como calcula el Executive la prioridad de un subproceso. Por tanto, la prioridad de un subproceso es relativa a la de su padre (excepto en IDLE y TIME_CRITICAL). Mediante suma y resta de la prioridad del padre obtenemos todo el rango de prioridades:

La ventaja de este sistema de las prioridades relativas es que si un proceso cambia su clase de prioridad durante su vida, sus subprocesos hijos tendrían sus prioridades automáticamente actualizadas.

Creación y destrucción de procesos

La llamada al sistema que crea un proceso es una de las más complejas de todo el API Win32. Vamos a comentarla para comprender mejor la forma en la que el Executive trabaja.

Un proceso se crea cuando un subproceso de otro proceso hace una llamada a:

BOOL CreateProcess (LPCTSTR lpszImageName, LPCTSTR lpszCommandLine, LPSECURITY_ATTRIBUTES lpsaProcess, LPSECURITY_ATTRIBUTES lpsaThread, BOOL fInheritHandles, DWORD fdwCreate, LPVOID lpvEnvironment, LPTSTR lpszCurDir, LPSTARTUPINFO lpsiStartInfo, LPROCESS_INFORMATION lppiProcInfo);

El Executive crea un espacio virtual de 4 Gb para el proceso, y también crea el subproceso primario. Veamos el significado de los parámetros:

lpszImageName: es el nombre del archivo que contiene el código ejecutable que el Executive asignará en el espacio virtual del proceso. Si es NULL, entonces se entenderá que viene dado en el siguiente parámetro.

lpszCommandLine: argumentos para el nombre del archivo

lpsaProcess, lpsaThread y fInheritHandles: los dos primeros son punteros con los que podemos dar unos atributos de seguridad para el proceso y su subproceso primario. Si pasamos NULL, el sistema pondrá los valores por defecto. Los parámetros son punteros a una estructura del tipo:

El campo lpSecurityDescriptor se refiere a permisos sobre el objeto proceso, pero no he encontrado más información al respecto.

De esta estructura vamos a destacar el campo bInheritHandle, que se refiere a la herencia. En Windows NT, cualquier objeto que creemos va a tener asociada una estructura de este tipo en donde se indicará, con el parámetro bInheritHandle, si dicho objeto es heredable o no. El objeto es propiedad de un proceso. Ese proceso puede crear procesos hijos; dichos procesos, por defecto, no heredarán ninguno de los objetos de su padre. Los procesos hijos que tengan la capacidad de heredar, heredarán aquellos objetos de su padre que tengan el campo bInheritHandle a TRUE.

Ahora bien, un proceso y un subproceso son también objetos. Por tanto, ambos objetos podrán ser heredables por otros procesos. Si el campo bInheritHandle es TRUE en la estructura apuntada por lpsaProcess, entonces el proceso que estamos creando será heredable por otros procesos hijos de su mismo padre.

Si el campo bInheritHandle es TRUE en la estructura apuntada por lpsaThread, entonces e subproceso primario del proceso que estamos creando será igualmente heredable.

Resta explicar el parámetro fInheritHandles. Si vale TRUE, entonces el proceso que estamos creando podrá heredar todos los objetos heredables de su padre (es decir, aquellos objetos cuyo campo bInheritHandle sea TRUE).

No se debe confundir todo esto con herencia entre procesos y subprocesos hijos. Un subproceso siempre podrá tener acceso a los objetos creados por el proceso al que pertenece (o mejor dicho, creados por algún otro subproceso del proceso al que pertenece).

fdwCreate: es una máscara donde se pueden especificar (mediante OR lógica) muchos indicadores para el proceso a crear. Los más importantes son:la clase de prioridad del proceso: IDLE_PRIORITY_CLASS (desocupado), NORMAL_PRIORITY_CLASS (normal), HIGH_PRIORITY_CLASS (alta), REALTIME_PRIORITY_CLASS (tiempo real)si el proceso va a ser dormido al crearse, usando CREATE_SUSPENDED

lpvEnvironment: apunta a un bloque de memoria que contiene cadenas de entorno. Si vale NULL, usará las mismas cadenas que su proceso padre. Las cadenas de entorno no son más que variables con algún valor que usarán los procesos con algún fin, (por ejemplo, el directorio home, el path). Tiene un significado similar al concepto de entorno de UNIX.

lpszCurDir: cadena con directorio y unidad de trabajo para el nuevo proceso.

lpsiStartInfo: apunta a una estructura bastante grande que no vamos a escribir. Los campos de dicha estructura dan informaciones al subsistema Win32 como por ejemplo si el proceso va a estar basado en GUI o en consola (GUI es con ventanas; consola es simulando el modo texto), el tamaño de la ventana inicial del proceso, las coordenadas de dicha ventana, su tamaño, su título …

En hprocess y hThread el Executive devuelve un par de descriptores a los objetos proceso y subproceso primario recién creados, y que servirán para hacer referencias a los mismos. Cada vez que el Executive crea cualquier objeto, asocia con dicho objeto un contador de uso. Cada vez que un proceso distinto usa un mismo objeto, incrementa el contador en 1. Cada vez que un proceso libera un objeto, decrementa el contador en 1. Cuando el contador de uso de un objeto es 0, el Executive destruye el objeto. Pues bien, cuando CreateProcess devuelve el control, los objetos proceso y subproceso primario tienen sus respectivos contadores con valor 2. De este modo, para que el Executive pueda destruirlos, habrán de ser liberados dos veces: una, cuando ellos mismos terminen (el contador pasaría a valer 1), y otra, cuando el proceso padre los libere (o sea, cuando cierre los descriptores; así, sus contadores valdrían 0 y 0, y el Executive los destruiría). De aquí es infiere que es vital que el proceso padre cierre esos descriptores (si no, no se destruirían los objetos y podría desbordarse la memoria). La llamada para cerrar descriptores es

BOOL CloseHandle (HANDLE hobject);

dwProcessId y dwThreadId son unos identificadores únicos que el Executive asocia al proceso y subproceso primario, respectivamente, análogos al PID en UNIX.

Hasta aquí la llamada al sistema que nos permite crear procesos. La llamada para finalizar el proceso es, afortunadamente, mucho más simple:

VOID ExitProcess (UINT fuExitCode); que devuelve el entero fuExitCode, que es un código de salida que el proceso envía antes de finalizar (que diga si ha finalizado con éxito, si no, etc). Cuando un proceso termina, se realizan las siguientes acciones:

Todos los subprocesos del proceso finalizan

Se cierran todos los descriptores de objetos del Executive y de Win32 abiertos por el proceso

El estado del objeto proceso para a estar señalado

El estado de terminación del proceso se pone al código de salida adecuado

Hemos dicho que el objeto proceso se pone a estado señalado. Un objeto puede tener dos estados: señalado y no señalado, estados que utiliza el sistema y los propios procesos para varias funciones. El curioso lector puede consultar el apartado de "Comunicación entre procesos".

Creación y destrucción de subprocesos

Análogamente a como nos hemos auxiliado de la llamada al sistema CreateProcess para comprender el mecanismo de creación de procesos, vamos a hacer lo propio para la creación de subprocesos. Un subproceso se crea cuando otro subproceso hace una llamada a:

HANDLE CreateThread (LPSECURITY_ATTRIBUTES lpsa, DWORD cbStack, LPTHREAD_START_ROUTINE lpStartAddr, LPVOID lpvThreadParm, DWORD fdwCreate, LPDWORD lpIDThread);

lpsa: tiene el mismo significado que en CreateProcess, es decir, un puntero a una estructura SECURITY_ATTRIBUTES, donde se especifican permisos del subproceso y si es heredable o no.

cbStack: vamos a aprovechar este parámetro para explicar la pila de un subproceso. Todo subproceso tiene una pila asociada situada en el espacio virtual del proceso al que pertenece. Virtualmente, la pila tiene un tamaño por defecto de 1 Mb (y además es el máximo; tamaños inferiores pueden ser indicados al enlazar la aplicación). De esa pila virtual el subproceso puede tener asignada en memoria un trocito. El tamaño de ese trocito viene dado por el parámetro cbStack, y por defecto es 1 página (4 Kb). Técnicamente, se dice que la pila tiene reservado un espacio de 1 Mb, y asignado un espacio de cbStack bytes. (el significado de ambos términos lo veremos detenidamente en el capítulo de administración de la memoria). Si el subproceso desborda su trocito de pila asignado en memoria se eleva una excepción; el Executive captura la excepción y asigna otros cbStack bytes en memoria física para la pila del subproceso. Por tanto, la pila crece dinámicamente en trozos de cbStack bytes. Lo más eficiente es que cbStack sea múltiplo del tamaño de la página.

lpStartAddr, lpThreadParm: ya dijimos que todo subproceso ejecuta una porción de código del proceso al que pertenece. Este parámetro apunta a la función que contiene el código a ejecutar por nuestro subproceso. Es posible hacer que varios subprocesos tengan la misma función asociada. El perfil de la función es fijo:

El parámetro lpvThreadParm de la función es justamente el mismo que se le pasa a CreateThread; de hecho, el sistema se limita a pasar dicho parámetro a la función asociada al subproceso cuándo éste comienza su ejecución.

El parámetro puede ser un valor de 32 bits o un puntero de 32 bits. Puede servir para dar algún tipo de inicialización al subproceso.

El parámetro dwresult de la anterior función es un código de salida que el subproceso devuelve cuando acaba de ejecutar código. Es similar al código que devuelven los procesos al acabar.

fdwCreate: si vale 0, entonces el subproceso comienza a ejecutarse en cuanto esté creado. Si vale CREATE_SUSPENDED, entonces se creará, pero automáticamente será suspendido.

lpIDThread: debe ser un puntero a una estructura DWORD, donde el Executive pondrá el identificador que le ha asignado al subproceso. Es obligatorio pasar una dirección válida.

El subproceso recién creado iniciará su ejecución inmediatamente antes del retorno de CreateThread (a menos que hayamos especificado el indicador CREATE_SUSPENDED).

Comunicación y Sincronización de Procesos Mediante Objetos

En Windows NT, los mecanismos clásicos de sincronización entre procesos (como los semáforos, las regiones críticas, los sucesos, etc.) son tratados como objetos. Es más, existen objetos no específicos de sincronización pero que también pueden ser usados con estos fines. Por tanto, vamos en primer lugar a enumerar todos los objetos de sincronización y a dar algunas características globales, para posteriormente adentrarnos a estudiar los más importantes.

Podemos sincronizar subprocesos mediante alguno de los siguientes objetos:

• Semáforos
• Mutexes
• Sucesos
• Archivos
• Procesos
• Subprocesos
• Entrada del terminal
• Notificación de cambio de archivo

Antes hemos mencionado las regiones críticas. Aunque Windows NT las incluye como mecanismo de sincronización, no las trata explícitamente como objeto. No obstante también las estudiaremos en este apartado por mantener la homogeneidad.

Como ya esbozamos en el capítulo de los procesos, en cualquier instante un objeto está en uno de dos estados: señalado (1) y no señalado (0). Cada estado tiene un significado dependiendo de la clase del objeto.

Por ejemplo, en el apartado anterior vimos que durante la vida de un proceso o un subproceso su estado era no señalado, pero que al morir pasaban al estado señalado. De aquí que ambos tipos de objetos sirvan para la sincronización. Por ejemplo, un subproceso A puede querer dormir hasta que otro proceso/subproceso B acabe; por tanto, A dormirá mientras el objeto asociado al B esté no señalado. En cuanto B pase a señalado, A despertará.

Igualmente, un subproceso se puede sincronizar con el fin de una lectura/escritura en un archivo. En general, cuando alguna de estas operaciones finalizan, el objeto archivo en cuestión pasa a estado señalado.

El objeto asociado a la entrada de teclado se pone señalado cuando existe algo en el buffer de entrada. La aplicación de este hecho para sincronización es evidente. Un subproceso puede así estar durmiendo mientras el buffer esté vacío.

El resto de objetos los veremos con más detalle a lo largo de este capítulo. Pero antes vamos a dar las llamadas al sistema que se utilizan para la sincronización con objetos.

Se trata de:

DWORD WaitForSingleObject (HANDLE hObject, DWORD dwTimeout);

Esta llamada simplemente mantiene al subproceso que la realiza dormido hasta que el objeto identificado por hObject pase al estado señalado. El parámetro dwTimeout indica el tiempo (en ms) que el subproceso quiere esperar por el objeto. Si vale 0, entonces la llamada sólo hace una comprobación del estado y retorna inmediatamente; si devuelve WAIT_OBJECT_0, el objeto estaba señalado; si devuelve WAIT_TIMEOUT, el objeto estaba no señalado. Si como tiempo metemos INFINITE, el subproceso dormirá hasta que el objeto pase a señalado. Hay un par de códigos de salida más que comentaremos en su momento (cuando expliquemos los mutex).

DWORD WaitForMultipleObjects (DWORD cObjects, LPHANDLE lpHandles, BOOL bWaitAll, DWORD dwTimeout);

Es parecida a la anterior pero da la posibilidad de esperar por varios objetos o bien por alguno de una lista de objetos. cObjects indica el número de objetos a comprobar. lpHandles apunta a una matriz que contiene descriptores a los objetos. El booleano bWaitAll indica si queremos esperar a que todos los objetos pasen a estado señalado o tan sólo uno, y dwTimeout es el tiempo a esperar. Si hay varios objetos que han pasado al estado señalado, la llamada coge sus descriptores, toma el menor y devuelve su posición dentro de la matriz (sumada a un código de retorno análogo a los de WaitForSingleObject).

El tema de sincronización está íntimamente relacionado con el de interbloqueos. Supongamos que tenemos dos subprocesos A y B compitiendo por dos objetos 1 y 2, esperando a que ambos estén señalados, para lo cual han hecho sendas llamadas a WaitForMultipleObjects. Supongamos que 1 pasa a estado señalado. Y supongamos que el Executive decidiera otorgar ese hecho al proceso A, colocando a 1 de nuevo a no señalado. Mientras tanto, 2 pasa también a señalado, y el Executive otorga este hecho a B, y también pone a 2 a no señalado. En esta situación, ninguno de los dos subprocesos podría terminar nunca, pues cada uno estaría esperando a que el objeto del otro pasara a señalado. Entonces A y B están interbloqueados. Para evitar esta situación, el Executive no entrega los objetos hasta que ambos estén señalados; en ese momento despertaría a uno de los subprocesos. El otro seguiría dormido hasta que el primer subproceso terminara de trabajar con los objetos.

A continuación se estudia cada uno de los objetos específicos de sincronización de Windows NT.

Secciones Críticas

Las secciones críticas son un mecanismo para sincronizar subprocesos pertenecientes a un mismo proceso, pero, como ya hemos indicado, no son objetos.

Una sección o región crítica (SC) es un trozo de código ejecutable tal que para que un subproceso pueda ejecutarlo se requiere que tenga acceso a una estructura de datos especial y compartida.

Dicha estructura es del tipo CRITICAL_SECTION, cuyos campos no son interesantes, y además no son accesibles directamente, sino a través de una llamada al subsistema Win32:

VOID InitializeCriticalSection (LPCRITICAL_SECTION lpCriticalSection);

Veamos algunas llamadas para manejar las SC:

VOID EnterCriticalSection (LPCRITICAL_SECTION lpCriticalSection);

VOID LeaveCriticalSection (LPCRITICAL_SECTION lpCriticalSection);

La primera sirve para que un subproceso solicite entrar en una SC. La segunda permite salir de la SC a un subproceso que esté dentro de la misma.

La función de entrar opera así: la primera vez que es llamada, se registra en la estructura CRITICAL_SECTION un identificador del subproceso que la posee.

Si antes de que el subproceso la abandone, el SO entrega la CPU a otro (el caso más frecuente), y entonces ese otro subproceso hace la llamada para entrar en la SC, entonces la función ve que la estructura ya está en uso, con lo que el segundo subproceso sería puesto a dormir.

Cuando la CPU vuelva al primero y éste haga una llamada para salir, la estructura será asignada al segundo subproceso.

Si un subproceso vuelve a llamar a la función de entrar estando ya dentro de la SC, simplemente se incrementará un contador de uso asociado con el objeto SC. Más tarde, deberá hacer tantas otras llamadas a la función de salir para poner el contador a 0; en caso contrario, ningún otro subproceso podría ocupar la SC.

La estructura CRITICAL_SECTION y todos los recursos que el SO le hubiera asignado se pueden eliminar haciendo una llamada a

VOID DeleteCriticalSection (LPCRITICAL_SECTION lpCriticalSection);

Sería catastrófico usar esta función estando un subproceso dentro.

Exclusión Mutua (Mutex)

Los objetos exclusión mutua (abreviadamente mutex, de mutual exclusión) son muy parecidos a las SC, pero permiten sincronizar subprocesos pertenecientes a procesos distintos.

Se crean con la llamada:

HANDLE CreateMutex (LPSECURITY_ATTRIBUTES lpsa, BOOL fInitialOwner, LPTSRT lpszMutexName);

fInitialOwner: dice si el subproceso que crea el mutex ha de ser su propietario inicial o no. Si vale TRUE, entonces el estado inicial del objeto mutex sería no señalado, por lo que todo subproceso que espere por él sería inmediatamente puesto a dormir. Si vale FALSE, el mutex se crea con estado señalado, por lo que al primer proceso que estuviera esperando le sería asignado y podría continuar ejecutándose.

lpszMutexName: apunta a una cadena con el nombre que le hemos querido dar al objeto (o NULL si no se pone un nombre).

La llamada devuelve un descriptor al objeto creado.

Si otro subproceso llamara a la función pasándole el mismo nombre de mutex, el SO comprobaría que ya está creado y devolvería otro descriptor al mismo objeto.

HANDLE OpenMutex (DWORD fwdAccess, BOOL fInherit, LPTSTR lpszMutexName);

Esta función comprobaría si existe algún objeto mutex con nombre lpszMutexName. Si es así, devolvería un descriptor al mismo. Si no, devolvería NULL. El booleano fInherit permite que el mutex sea heredado por los subprocesos hijos.

Si el mutex no tuviera nombre, un subproceso podría obtener un descriptor al mismo llamando a DuplicateHandle.

Otra diferencia de los mutex con las SC (y en general con cualquier objeto de sincronización en Windows NT) es que un subproceso mantiene la propiedad de un mutex hasta que quiera liberarlo, pero hasta el punto de que, si el subproceso muere y no ha liberado al mutex, éste seguiría siendo de su propiedad.

Así, si un mutex está libre (señalado) y es tomado por un subproceso (pasa a no señalado), y dicho subproceso finaliza antes de liberarlo, el estado del mutex pasaría a señalado; los subprocesos que estuvieran esperando por el mutex serían despertados pero no se les asignaría el objeto a ninguno, sino que con el valor WAIT_ABANDONED de retorno de las llamadas WaitFor…Object(s) se les informaría de lo que ha sucedido, de que el mutex no ha sido liberado sino abandonado. Esto se considera como una situación de fallo en un programa.

Para liberar un mutex usaremos la llamada

BOOL ReleaseMutex (HANDLE hMutex);

Donde:

hMutex: es un descriptor al objeto. La función decrementa el contador de uso que el subproceso tiene sobre el mutex. Cuando sea 0, el objeto podrá ser asignado al primer subproceso que por él esté esperando, igual que con las SC.

Semáforos

Un semáforo es un objeto distinto de las SC y los mutex. A diferencia de ambos, el objeto semáforo puede ser poseído a la vez por varios subprocesos, y no posee dentro ningún identificador del subproceso/s que lo está usando. Lo que tiene es un contador de recursos, que indica el número de subprocesos que pueden acceder al semáforo. Cuando un subproceso toma el objeto semáforo, el SO mira si el contador de recursos del mismo es 0. De ser así, pone al subproceso a dormir. Si no es 0, asigna el semáforo al subproceso y decrementa el contador. Cada vez que un subproceso libera el semáforo, se incrementa el contador.

Un semáforo está señalado cuando su contador es mayor que 0, y no señalado cuando su contador vale 0.

Un semáforo se crea con la llamada:

HANDLE CreateSemaphore (LPSECURITY_ATTIBUTES lpsa, LONG cSemInitial, LONG cSemMax, LPTSTR lpszSemName);

cSemInitial es el valor inicial no negativo del contador de recursos.

cSemMax es el valor máximo que puede alcanzar dicho contador (por tanto 0 <= cSemInitial <= cSemMax)

lpszSemName es el nombre que le damos al objeto.

HANDLE OpenSemaphore (DWORD fdwAccess, BOOL fInherit, LPTSTR lpszName);

La semántica de esta llamada es análoga a la de OpenMutex.

Para incrementar el contador de referencia del semáforo se usa:

HANDLE ReleaseSemaphore (HANDLE hSemaphore, LONG cRelease, LPLONG lplPrevious);

Donde:

cRelease indica el número de veces que queremos incrementar el contador (el número de veces que liberamos el semáforo). A la vuelta de la función, tendremos en lplPrevious un puntero al valor anterior del contador. Por tanto, si queremos averiguar el valor del contador tenemos que modificarlo. Ni siquiera llamando a la función con cRelease igual a 0 podríamos saber el valor anterior sin modificar el semáforo, pues entonces la función devuelve 0 como dato apuntado por lplPrevious.

Sucesos.

Los sucesos son objetos utilizados para indicar a los subprocesos que ha ocurrido algo en el entorno. Se puede distinguir dos tipos de objetos suceso:

Sucesos con inicialización manual.

Sucesos con autoinicialización.

Cualquier objeto suceso podrá estar en estado señalado o no señalado. No señalado significa que la situación asociada con el objeto aún no ha ocurrido. Señalado indica que sí se ha producido.

Ambos tipos de objeto se crean con la misma llamada:

HANDLE CreateEvent (LPSECURITY_ATTIBUTES lpsa, VOOL fManualReset, BOOL fInitialState, LPTSTR lpszEventName);

fManualReset a TRUE le indicará al SO que queremos crear un suceso de inicialización manual, y a FALSE, un suceso de autoinicialización.

fInitialState indica el estado inicial del objeto; un valor TRUE significa que el suceso se creará como obejto señalado, y a FALSE como no señalado.

Como vimos con los otros tipos de objetos de sincronización, otros procesos pueden acceder al mismo objeto usando CreateEvent y el mismo nombre, o usando la herencia, o con DuplicateHandle, o con:

HANDLE OpenEvent (DWORD fdwAccess, BOOL fInherit, LPTSTR lpszName);

Sucesos con inicialización manual (manual reset)

Este tipo de objetos se usan para que, cuando el suceso ocurra, es decir, se ponga a señalado, todos los subprocesos que esperaban por ese suceso se despierten a la vez y todos puedan seguir ejecutándose. Por tanto, ahora las funciones WaitFor…Objext(s) no van a tocar el estado del objeto, sino que debe hacerlo el propio subproceso que creó el objeto. Dicho subproceso puede usar las llamadas:

BOOL SetEvent (HANDLE hEvent);

BOOL ResetEvent (HANDLE hEvent);

que ponen, respectivamente, el suceso identificado por hEvent en estado señalado y no señalado. O sea, con SetEvent indicaremos que la situación asociada al obejto se ha producido, y con ResetEvent indicaremos lo contrario.

Existe una llamada muy útil con este tipo de objetos:

BOOL PulseEvent (HANDLE hEvent);

que le da un "pulso" al suceso hEvent: lo pone en estado señalado, con lo que se libera a todos los subprocesos en espera (que se seguirán ejecutando), y entonces lo pone a no señalado, con lo que los subprocesos que a partir de ese momento esperen por el suceso serán dormidos. Por tanto, equivale a SetEvent + liberación + ResetEvent.

Sucesos con autoinicialización (auto-reset)

Con estos objetos las funciones WaitFor…Object(s) van a funcionar como con cualquier otro tipo de objeto. Por tanto, cuando la situación asociada con el suceso ocurra y éste se ponga a señalado (con SetEvent), sólo uno de los subprocesos que estaban esperando podrá continuar, y su función WaitFor…Object(s) correspondiente pondrá el estado del objeto a no señalado. La función ResetEvent no tendría efecto aquí. La función PulseEvent pondría el suceso a señalado, liberaría un sólo subproceso de los que están esperando, y pondría el suceso a no señalado.