Hilos En Posix

TALLER DEL PRIMER CORTE

PRESENTADO POR:

CARLOS ESTEBAN MARTÍNEZ

46091010

PRESENTADO A:

ING. ERWIN MEZA

UNIVERSIDAD DEL CAUCA

FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

PROGRAMA INGENIERÍA DE SISTEMAS

SISTEMAS OPERATIVOS

POPAYÁN

2012

1.1. FUNCIONAMIENTO DE LA PLANIFICACION DE PROCESOS E HILOS EN LINUX:

El Process Scheduler (SCHED), es el componente del kernel encargado de controlar el acceso de los procesos al CPU. El SCHED es el componente de bajo nivel más importante del sistemas; todos los demás (incluyendo los módulos de acceso a disco, controladores de video, etc.), dependen directamente de él.

Los procesos en Linux pueden ser divididos en tres categorías, relacionadas con la prioridad: interactivos, por lotes y de tiempo real. Los procesos TR son manejados bien por un algoritmo FIFO o RR. Los demás procesos son despachados utilizando planificación RR con un sistema de envejecimiento basado en créditos, donde el siguiente proceso a ejecutar es aquel que más créditos posea. Los procesos TR son considerados prioritarios sobre cualquier otro proceso en el sistema, por lo que serán ejecutados antes que los demás. Por otro lado, un proceso puede estar en alguno de estos estados: en ejecución, en espera, detenido o zombie (un proceso que, aunque ha finalizado su ejecución, mantiene su PCB en el sistema).

Algunos aspectos de la estructura interna del kernel que caben destacarse son:

• La PCB está representada por la estructura task_struct. Ésta indica el tipo de planificación (FIFO,RR) por medio del campo policy, la prioridad (priority), el contador del programa (counter), entre otros.

• La función goodness otorga una “calificación” al proceso pasado como parámetro. Dicha puntuación oscila entre -1000 (no elegible) y +1000 (TR). Los procesos que comparten una zona de memoria ganan una puntuación equivalente a su prioridad.

• El quantum varía según el proceso y su prioridad. La duración base es de aprox. 200ms.

• La función switch_to es la encargada de salvar la información de un proceso y cargar el siguiente.

• Las funciones sched_{get/set}scheduler se refieren al mecanismo de planificación asociado a ese proceso. De igual forma el equivalente con ...param devuelve/fija la prioridad de un proceso.

• Una nueva copia del proceso actual es creada mediante la llamada al sistema fork. Para ejecutar un nuevo programa se utiliza la función execve.

1.2. PLANIFICACIÓN DE PROCESOS EN WINDOWS NT:

El kernel de Windows NT está diseñado utilizando POO. Posee una capa de abstracción de hardware (HAL), la cual es la única que se comunica directamente con el procesador; el resto del kernel está diseñado para utilizar la interfaz de la HAL. La unidad mínima de ejecución no es el proceso sino el hilo. Un hilo puede estar en alguno de estos seis estados: listo, standby (siguiente a ejecutar), en ejecución, en espera, en transición (un nuevo hilo) y terminado.

Windows NT utiliza una planificación basada en colas múltiples de prioridades. Posee 32 niveles de colas, clasificadas en clas de TR (16-31) y clase variable (0-15). Las colas se recorren de mayor a menor ejecutando los hilos asociados. Cada cola es manejada por por medio de un algoritmo de RR, aun así, si un hilo de mayor prioridad llega, el procesador le es asignado a éste.

2.0. HISTORIA DE POSIX

POSIX fue nombrado (como tantas cosas en el mundo del software Unix) por Richard Stallman. Es el acrónimo de "Portable Operating System Interface" - X, es decir, una definición de un sistema operativo portable de la API de UNIX. La razón de la existencia de la norma POSIX es interesante, y está en la historia de la familia de sistemas operativos UNIX.

Como es sabido, Unix fue creado en laboratorios AT & T Bell por Ken Thompson y Dennis Richie en 1969. No originalmente diseñado para su comercialización, el código fuente se envió a las universidades de todo el mundo, sobre todo en Berkeley, en California. Uno de los primeros sistemas operativos verdaderamente portátiles del mundo, Unix pronto se dividió en diferentes versiones,puesto que la gente iba modificado el código fuente para satisfacer sus propias necesidades. Una vez que compañías como Sun Microsystems y SCO (Santa Cruz) comenzaron a comercializar Unix, el sistema original de Unix llamado interfaz de programación de aplicaciones (API) continuó siendo el núcleo del sistema Unix, pero cada compañía agregó extensiones propias para diferenciar su versión de Unix. Así comenzó la primera de las "guerras Unix". Para los proveedores de software independientes (ISV) las variantes de propiedad eran una pesadilla. Nno se podia asumir que el código funcionara correctamente en Unix sin siquiera compilarlo en otra versión.

A finales de 1980, en un intento de crear una API común para todos los sistemas Unix para solucionar este problema, nació el conjunto de normas POSIX. Debido al hecho de que nadie confiaba en ninguno de los vendedores de Unix, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) guió el proceso de las normas y creó la serie 1003, conocido como POSIX. Los estándares POSIX abarcan mucho más que el funcionamiento del sistema API, pero sólo vamos a hablar de la parte estándar de programación API de POSIX.

Leer el manual estándar POSIX, es muy interesante. Se lee como un instrumento legal, cada línea de cada sección está numerada para que pueda ser mencionado en otras partes del texto. Es realmente detallado, la razón de tal detalle es que fue diseñado para ser una especificación completa de cómo un sistema Unix tiene que comportarse cuando se llama desde una aplicación. El secreto es que estaba destinado a permitir que quien lea la especificación pueda re-implementar completamente

...