Hebras, SMP, y Microkernels

Presentación del tema: "Hebras, SMP, y Microkernels"— Transcripción de la presentación:

1 Hebras, SMP, y Microkernels
Capítulo 4

2 Dos características de un proceso
Propietario de Recursos un proceso incluye un espacio virtual de direcciones donde se almacena la imagen del proceso. En un momento dado el SO puede asignar recursos al proceso Es planificado/ejecutado – sigue un camino de ejecución que puede intercalarse con la ejecución de otros procesos. Así un proceso puede estar Running, Ready, etc. Estas dos características son tratadas independientemente por el SO Entidad que se ejecuta/despacha es llamada hebra Entidad dueña de recursos es llamado proceso

3 Procesamiento Multihebra
La capacidad del SO de soportar múltiples hebras de ejecución dentro de un proceso MS-DOS soporta sólo una hebra (y sólo un proceso) UNIX soporta múltiples procesos de usuario, pero sólo una hebra por proceso Windows, Solaris, Linux, Mach, y OS/2 soportan múltiples hebra En este caso, el proceso es asociado con Un espacio virtual de direcciones que contiene la imagen del proceso Acceso protegido al procesador, otros procesos, archivos, etc.

4

5 Una hebra posee Un estado de ejecución (running, ready, etc.)
Un contexto de hebra, cuando no está ejecutándose Un stack de ejecución Almacenamiento estático de memoria para variables locales Derecho a acceder la memoria y recursos del proceso al que pertenece Todas la hebras de un proceso comparten esta propiedad

6 Todas la hebras de un proceso comparten los recursos de un proceso
Cada hebra puede tener su propio estado, pero cuando el proceso se suspende, todas las hebras se suspenden. Cuando el proceso termina, todas la hebras terminan Cuando una hebra modifica un dato en memoria global, las otras hebras ven el resultado de la modificación

7 Beneficios de las hebras
Demora menos crear y eleminar una hebra que un proceso Demora menos hacer cambio de contexto entre hebras de un mismo proceso que entre dos procesos Ya que las hebras de un proceso comparten memoria y archivos, ellas se pueden comunicar sin necesidad de invocar rutinas del kernel

8 Ejemplo de uso de hebras en un sistema mono usuario multiprogramado
Ejecución concurrente de tareas background y foreground: Ej cómputo y manejo de interface Procesamiento asíncrono Ej: Guarar periódicamente contenidos de editor de texto Aumento velociad de ejecución Intercalar procesamiento con lectura de próximo job Estructura modular del programa

9 Estados de una hebra Los estados típico son Running, Ready, y Blocked
Cuando un proceso es suspendido (swap-out), todas las hebras son suspendiadas Si una hebra es bloqueada (estado Blocked), ¿qué pasa con las otras hebras del mismo proceso? (ver ejemplo que sigue) Operaciones típicas que involucran estados Spawn Un proceso Una hebra Block. Por ejemplo debido a I/O Unblock Término

10 RPC monohebra. RPC multihebra.

11 Multi hebras en mono procesador

12 Hebras nivel usuario versus nivel kernel
Existen dos categorías generales de implementación de hebras: nivel de usuario y nivel de kernel Nivel de usuario Toda la administración de las hebras la realiza la aplicación misma (proceso) o por librerías de manejo de hebras El kernel no sabe que el proceso tiene varias hebras y planifica (scheduled) el proceso no las hebras El kernel podría ser mono hebrado

13

14 Hebras a nivel de usuario
Ventajas Cambio de contexto no necesita privilegios del kernel y es más rápido Scheduling puede depender y ser específico a la aplicación Pueden ser implementadas en cualquier SO, y no requieren cambios al kernel Desventajas Cuando una hebra se boquea, el proceso entero se bloquea Aunque exista varios procesadores, la hebras no podrían hacer uso de ellos en forma paralela

15 Hebras a nivel de kernel
Toda la administración de hebras la realiza el kernel (sistema puro) Windows es un ejemplo de este modo El kernel mantiene información de contexto por el proceso y por la hebras del proceso Scheduling es al nivel de hebra Ventajas: Se puede explotar múltiples procesadores Si una hebra se bloquea, el control de la CPU puede pasar a otra hebra Desventaja: cambio de contexto entre hebras requiere la intervención del kernel

16 VAX Running UNIX-Like Operating System

17 Sistemas híbridos La creación de hebras se hace a nivel de usuario
Parte de la sincronización y scheduling tambien se hace a nivel de usuario Ejemplo es Solaris La hebras a nivel de usuario se mapean (corren) sobre un número variable de hebras de kernel

18 Otros modelos

19 Multiprocesamiento simétrico (SMP)

20 Modelos de computación
Single Instruction Single Data (SISD) stream Un flujo simple de instrucciones operan sobre una sequencia simple de datos almacenados en memoria Single Instruction Multiple Data (SIMD) stream Un mismo flujo de instrucciones opera sobre conjuntos diferentes de datos por diferentes unidades de procesamiento (procesadores vectoriales) Multiple Instruction Single Data (MISD) stream Una secuencia de datos se transmite a un conjunto de procesadores, los cuales ejecutan un operación distinta sobre ellos (nunca implementada) Multiple Instruction Multiple Data (MIMD) stream Un conjunto de procesadores ejecutan instrucciones diferentes sobre conjuntos de datos diferentes simultáneamente

21

22 Modelos de asignación de procesos
Maestro/esclavo : El kernel del SO siempre corre en un procesador dado (maestro). El maestro envia procesos usuarios a los esclavos Ventajas: simple, Desventajas: Si se cae el maestro, todo el sistema se cae. También, el maestro puede ser un cuello de botella Simétrico (SMP): El kernel se puede ejecutar en cualquier procesador El kernel se puede construir como múltiples procesos o hebras Cada procesador puede planifica sus propios procesos desde un pool de procesos disponibles Desventaja: complicado

23

24 Consideraciones de diseño de SO SMP
Ejecución simultánea de procesos o hebras El código del kernel debe ser reentrante Scheduling Cualquier procesador puede realizar su propio scheduling Sincronización Se debe controlar el acceso simultáneo a la memoria compartida y dispositivos de I/O compartidos Administración de memoria Además de todos los problemas típicos asociados con la administración de memoria, el SO debe explotar el paralelismo que el hardware le provee, como por ejemplo las memorias multipuerto Confiabilidad y tolerancia a fallas El SO debe estar preparado por si un procesador falla

25 Microkernels Núcleo pequeño del sistema operativo que provee sólo las funciones escenciales Muchos servicios que tradicionalmente son incluidos en el SO son dejados fuera del microkernel Drivers de los dispositivos Sistemas de archivos Administrador de memoria virtual Sistema de ventanas Servicios de seguridad

26 En un microkernel, los componentes externos a él son implementados como procesos servidores, los cuales se comunican con paso de mensajes a través del microkernel

27 Beneficios de una organizacion microkernel
Interface uniforme para pedir servicios por los procesos No hay distincion entre servicios a nivel de kernel o nivel de usuario Todos los servicios se proveen mediante paso de mensajes Extensibilidad Facilita la adición de nuevos servicios Sólo los servidores involucrados son modificados El microkernel no se modifica Flexibilidad Facilita la adición de nuevas características Facilita la eliminación características obsoletas Portabilidad Cambios para portar el SO a una nueva arquitectura se realizan sólo en el microkernel, no servicios Confiabilidad Diseño modular Es más facil depurar un microkernel pequeño que un gran SO monolítico

28 Diseño de Microkernel Un microkernel debe incluir funciones:
que dependen directamente del hardware de apoyo a los servidores operando en modo usuario Estas funciones caen en la siguientes categorias generales: Administración de bajo nivel de memoria Comunicación entre procesos I/O Administración de interrupciones

29 Windows Processes Implemented as objects
An executable process may contain one or more threads Both processes and thread objects have built-in synchronization capabilities

30

31 Windows Process Object

32 Windows Thread Object

33 Windows 2000 Thread States Ready Standby Running Waiting Transition
Terminated

34

35 Solaris Process includes the user’s address space, stack, and process control block User-level threads Lightweight processes (LWP) Kernel threads

36

37

38 Solaris Lightweight Data Structure
Identifier Priority Signal mask Saved values of user-level registers Kernel stack Resource usage and profiling data Pointer to the corresponding kernel thread Pointer to the process structure

39

40 Linux Task Data Structure
State Scheduling information Identifiers Interprocess communication Links Times and timers File system Address space Processor-specific context

41 Linux States of a Process
Running Interruptable Uninterruptable Stopped Zombie

42