Estructura y Procesos de un SO

ESTRUCTURA Y PROCESOS SO
Mg. Richard E. Mendoza G.
Docente

AGENDA
Sistemas Operativos | Curso 2015 | Estructura de los sistemas operativos 2/28
▪ Servicios del sistema operativo (system services).
▪ Llamados a sistema (system calls).
▪ Estructura del sistema. Máquinas virtuales.

SERVICIOS DEL SO
3/28
Sistemas Operativos | Curso 2015 | Estructura de los sistemas operativos
• El sistema brindará un entorno de ejecución de programas dónde se
dispondrá de un conjunto de servicios que serán accesible mediante
una interfase bien definida.
• Servicios básicos que debe brindar un sistema operativo:
▪ Ejecución de programas y administración de procesos.
▪ Operaciones de Entrada/Salida.
▪ Manipulación de sistemas de archivos.
▪ Comunicación entre procesos.
▪ Detección y manipulación de errores (excepciones).

EJECUCIÓN DE PROGRAMAS Y
ADMINISTRACIÓN DE PROCESOS
4/28
El sistema debe ser capaz de cargar un programa a memoria y ejecutarlo. Es
decir, crear un proceso.
Cada proceso cuenta con un contador de programa (PC, program counter)
que determina la próxima instrucción de código a ejecutar.
El proceso necesita de ciertos recursos (CPU, memoria, archivos y dispositivos
de E/S) para realizar su tarea.
El sistema operativo es responsable de las siguientes tareas:
• Mantener que partes de la memoria están siendo utilizadas y por quién.
• Decidir cuales procesos serán cargados a memoria cuando exista espacio
de memoria disponible.
• Asignar y quitar espacio de memoria según sea necesario.

• El sistema albergará muchos procesos compitiendo por los recursos
y será el responsable de proveer de medios o servicios para que
realicen su tarea:
▪ Crear y destruir procesos.
▪ Suspensión y reanudación de procesos.
▪ Proveer mecanismos para la cooperación (sincronización) y comunicación
entre los procesos.
▪ Proveer mecanismos para prever la generación de dead-locks o lograr salir
de ellos (opcional).
• El proceso deberá poder en algún momento finalizar su ejecución, ya
sea de forma normal o anormal (indicando un error).
5/28
EJECUCIÓN DE PROGRAMAS Y
ADMINISTRACIÓN DE PROCESOS

OPERACIONES DE ENTRADA/SALIDA
6/28
• Un programa en ejecución necesitará de operaciones de
Entrada/Salida para acceder a un archivo o dispositivo.
• Por eficiencia y protección los usuarios no accederán directamente al
dispositivo.
• El sistema operativo deberá encapsular y ocultar las características
específicas de los diferentes dispositivos de almacenamiento y ofrecer
mecanismos de acceso comunes para todos los medios de
almacenamiento.
• Para ello proveerá de:
▪ Un conjunto de servicios que provean la interfase con el subsistema e
implementen técnicas de cache, buffering y spooling.
▪ Una interfase cliente con el sistema operativo para los manejadores de
dispositivos o device drivers que permitirá interactuar (mediante cargas
dinámicas o no) con cualquier modelo de dispositivo.
▪ Device drivers específicos.
▪ Montaje y desmontaje (Mount/Dismount) de dispositivo.

MANIPULACIÓN DEL SISTEMA DE ARCHIVOS
Sistemas Operativos | Curso 2015 | Estructura de los sistemas operativos 7/28
• Se deberá proveer acceso al sistema de archivos.
• El sistema operativo es responsable de las siguientes actividades:
▪ Administrar el espacio libre.
▪ Asignación del lugar de la información.
▪ Algoritmos de planificación de disco.
• Proporciona una
almacenamiento en los diferentes dispositivos implementando
vista uniforme de todas las formas de
el
concepto de archivo como una colección arbitraria de bytes u otras
clases o organizaciones más sofisticadas.
• Implementará los métodos de:
▪ Abrir, cerrar, extender y borrar archivos
▪ Leer, escribir archivos
▪ Crear y borrar directorios

COMUNICACIÓN ENTRE PROCESOS
8/28
• Es deseable que los procesos puedan comunicarse.
• Se deberá proveer mecanismos de comunicación entre ellos ya sea
que estén en
compartida), o
el mismo computador (a través de memoria
en diferentes computadores (a través de
transferencias de paquetes de red entre los sistemas operativos
involucrados).
• También debe permitir la sincronización de procesos que trabajan en
conjunto.
• En el caso de sistemas remotos se generaliza el concepto de
dispositivo virtual implementando un manejador (driver) que
encapsula el acceso a estos dispositivos.

DETECCIÓN Y MANIPULACIÓN
DE ERRORES
9/28
• El sistema deberá tomar decisiones adecuadas ante eventuales
errores que ocurran y proveer una interfaz para manejarlos.
• Ejemplos:
▪ Fallo en un dispositivo de memoria.
▪ Fallo en la fuente de energía.
▪ Fallo en un programa.

SERVICIOS DEL SO
10/28
• Otros servicios de propósito general que deberá brindar el sistema
operativo son:
▪ Asignación de recursos.
▪ Contabilización.
▪ Protección, manejo de usuarios y permisos.
• Una vez que están definidos los servicios que brindará el sistema
operativo, se puede empezar a desarrollar la estructura del sistema.

ASIGNACIÓN DE RECURSOS
11/28
▪ Cuando hay varios procesos compitiendo por los recursos es
importante tener algoritmos eficientes de asignación
▪ Cada recurso tiene necesidades y por lo tanto algoritmos diferentes

CONTABILIZACIÓN
12/28
▪ Se quiere llevar un registro de que usuarios usan que recursos y en
que cantidad
▪ Permiten dimensionar y evaluar el estado del sistema

PROTECCIÓN, MANEJO DE
USUARIOS Y PERMISOS
13/28
▪ En un sistema multiusuario donde se ejecutan procesos en forma
concurrente se deben tomar medidas que garanticen la ausencia de
interferencia entre ellos.
▪ Por protección nos referimos a los mecanismos por los que se controla al
acceso de los procesos a los recursos.
▪ El mecanismo debe incorporar la posibilidad de definir reglas de acceso
y asegurar su verificación en toda ocasión que corresponda.

LLAMADOS AL SISTEMA
14/28
▪ Los llamados al sistema (system calls) son una interfaz, provista por el
núcleo, para que los procesos de usuarios accedan a los diferentes
servicios que brinda el sistema operativo.
▪ Al principio los system calls estaban desarrollados en lenguaje de la
arquitectura de la máquina.
▪ En los sistemas modernos están programados en lenguajes de
programación de alto nivel como C o C++.
▪ Los servicios son invocados por los procesos en modo usuario, cuando
ejecutan lo hacen en modo monitor, y al retornar vuelven al modo
usuario.
▪ Típicamente a los system calls se les asocia un número que los identifica
(en Linux son aproximadamente 350).

LLAMADOS AL SISTEMA
15/28
• La llamada aun system call incluye las siguientes tareas:
• Cargar los parámetros en el lugar adecuado (stack o registros).
• Cargar el número de system call en algún registro específico (Ej: eax en
Intel). Invocar a la interrupción por software (trap) adecuada (system call
handler).
• El hardware cambia el bit de modo a monitor e invoca al manejador de la
interrupción que controla que el número de system call pasado en el
registro sea menor que el mayor del sistema y, finalmente, invoca al
system call correspondiente.
• El valor retornado por el system call es puesto en un registro específico
(Ej.: eax en Intel).

LLAMADOS AL SISTEMA
16/28
• Existen 3 formas de pasar los parámetros al sistema operativo:
• A través de los registros: Se utilizan un conjunto de registros para pasar los
parámetros. Tiene el problema de la cantidad de parámetros es fija y que
restringe el tamaño del valor.
▪ En Intel se utilizan 5 registros: ebx, ecx, edx, esi, y edi.
▪ Un bloque de memoria apuntado a través de un registro.
▪ En el stack del proceso que realiza el llamado. El proceso guarda los
parámetros con operaciones push sobre el stack y el sistema operativo
los saca con la operación pop.
• De la misma forma se pueden recibir los datos de
respuesta

LLAMADOS AL SISTEMA
17/28

LLAMADOS AL SISTEMA
18/28
Los system calls se clasifican en distintos tipos:
Control de procesos
•Cargar, ejecutar, finalizar, abortar, obtener atributos, cargar atributos, esperar por
tiempo, esperar por un evento o señal, obtener o liberar memoria, etc.
Gestión de archivos
• Crear, borrar, abrir, cerrar, leer, escribir, obtener o cargar atributos, etc.
Gestión de dispositivos
•Requerir o liberar un dispositivo, leer o escribir, buscar o cargar atributos de un
dispositivo, etc.
Gestión de información del sistema
•Obtener o cargar la hora del sistema, datos del sistema, de procesos, etc.
Comunicaciones
• Crear o destruir conexiones, enviar o recibir mensajes, etc.

ESTRUCTURA DEL SISTEMA
19/28
La estructura interna de los sistemas operativos pueden ser muy
diferentes.
Se deben tener en cuenta:
Metas de los usuarios: ser amigable, intuitivo, confiable, seguro, rápido, etc.
Metas del sistema: fácil de diseñar, implementar y mantener, también
flexible, confiable y eficiente.
Diseño del sistema:
Sistema monolítico. Sistema en capas.
Sistema con micronúcleo (microkernel).

SISTEMA MONOLÍTICO
20/28
• No se tiene una estructura definida.
• El sistema es escrito como una colección de procedimientos, que
pueden ser invocados por cualquier otro.
• No existe “ocultación de información”, ya que cualquier procedimiento
puede invocar a otro.
• Si bien todo procedimiento es público y accesible a cualquiera, es
posible tener buenos diseños y lograr, de esa forma, buena eficiencia en
el sistema.
▪
▪
Ej.: MS-DOS.
– Los componentes pueden invocar procedimientos de cualquiera.
Ej.: Linux
– Linux es un núcleo monolítico que a logrado un buen diseño orientado
a objetos (sistema modular).

SISTEMA EN CAPAS
• Se organiza el diseño en una
jerarquía de capas
construidas una encima de la
otra.
• Los servicios que brinda cada
capa son expuestos en una
interfase pública y son
consumidos solamente por los
de la capa de arriba.
• La capa 0 es el hardware y la
N es la de procesos de
usuario.
21/28

SISTEMA EN CAPAS
22/28
Ventajas:
▪ Modularidad.
▪ Depuración y verificación de cada capa por separado.
Desventajas:
▪ Alto costo de definición de cada capa en la etapa de diseño.
▪ Menos eficiente frente al sistema monolítico ya que sufre de
overhead al pasar por cada capa.

SISTEMA EN CAPAS
▪ Ej.: en capas – OS/2.
23/28

SISTEMA CON MICRONÚCLEO
(MICROKERNEL)
24/28
Se constituye de un núcleo un manejo minimo de que brinde procesos,
memoria y, además, provea de una capa de comunicación entre
procesos.
▪ La capa de comunicación es la funcionalidad principal del sistema.
▪ Los restantes servicios del sistema son construidos como procesos
separados al micronúcleo que ejecutan en modo usuario.
▪ El acceso los servicios del sistema se realiza a través de pasaje de
mensajes.

SISTEMA CON MICRONÚCLEO
Ventajas:
Aumenta la portabilidad y escalabilidad ya que encapsula las características
físicas del sistema
Para incorporar un nuevo servicio no es necesario modificar el núcleo. Es más
seguro ya que los servicios corren en modo usuario.
El diseño simple y funcional típicamente resulta en un sistema más confiable.
25/28

MÁQUINAS VIRTUALES
26/28
▪
▪
▪
Se puede ver como una extensión de los sistemas multiprogramados
pero a más bajo nivel
Los procesos no solamente trabajan sobre el sistema operativo como si
fueran el único proceso en el sistema sino que tienen una copia virtual
del hardware de la CPU
Las máquinas virtuales corren como procesos a nivel de usuario y el
administrador de MVs (hypervisor) implementa un modo usuario virtual y
un modo administrador virtual
También se implementan discos virtuales sobre los discos reales para las
máquinas virtuales
▪ Dos modos básicos
– Tipo 1: el administrador corre directamente sobre el hardware
– Tipo 2: el administrador corre como un proceso sobre un sistema operativo
normal

MÁQUINAS VIRTUALES:
BENEFICIOS
27/28
• Seguridad
▪ Los procesos en cada máquina virtual son completamente independientes
de los procesos en las otras
• Facilidad de desarrollo
▪ Se pude correr un sistema operativo de test en una máquina virtual sin
correr riesgos con el sistema real
• Flexibilidad
▪ Correr un sistema operativo de una arquitectura en una máquina diferente
• Alta disponibilidad
▪ En caso de falla de una MV se puede levantar otra rápidamente en
otro hardware

MÁQUINAS VIRTUALES:
DESVENTAJAS
28/28
▪ Los tiempos de las operaciones pueden tardar más que en un
sistema real
• Tiempo adicional por traducir las operaciones
▪ Tiempo de respuesta de la máquina muy poco predecible por uso
del sistema operativo de base u otras MVs
• No apropiado para sistemas de tiempo real

PROCESOS SO
Mg. Richard E. Mendoza G.
Docente

AGENDA
30/3
Sistemas Operativos | Curso 2015 | Procesos
▪ Proceso.
• Definición de proceso.
• Contador de programa.
• Memoria de los procesos.
▪ Estados de los procesos.
• Transiciones entre los estados.
▪ Bloque descriptor de proceso (PCB).
▪ Creación de procesos.
▪ Listas y colas de procesos.
▪ Cambio de contexto (context switch). Hilos (Threads).
• Threads a nivel de usuario.
• Threads a nivel de núcleo del sistema.
• Modelos de threads.
AGENDA

DEFINICIÓN DE PROCESO
31/3
▪ El principal concepto en cualquier sistema operativo es el de
proceso. Un proceso es un programa en ejecución, incluyendo el
valor del
▪ program counter, los registros y las variables.
▪ Conceptualmente, cada proceso tiene un hilo (thread) de ejecución
que es visto como un CPU virtual.
▪ El recurso procesador es alternado entre los diferentes procesos
que existan en el sistema, dando la idea de que ejecutan en paralelo
(multiprogramación)

CONTADOR DE PROGRAMA
Cada proceso tiene su program counter, y avanza cuando el proceso tiene
asignado el recurso procesador. A su vez, a cada proceso se le asigna un
número que lo identifica entre los demás: identificador de proceso (process id)
32/3

MEMORIA DE LOS PROCESOS
▪ Un proceso en memoria se constituye
de varias secciones:
▪ Código (text): Instrucciones del proceso.
▪ Datos (data): Variables globales del
proceso.
▪ Memoria dinánica (heap): Memoria
dinámica que genera el proceso.
▪ Pila (stack): Utilizado para preservar el
estado en la invocación anidada de
procedimientos y funciones.
33/35

ESTADOS DE LOS PROCESOS
34/35
▪ El estado de un proceso es definido por la actividad corriente en que
se encuentra.
▪ Los estados de un proceso son:
• Nuevo (new): Cuando el proceso es creado.
• Ejecutando (running): El proceso tiene asignado un procesador y está
ejecutando sus instrucciones.
• Bloqueado (waiting): El proceso está esperando por un evento (que
se complete un pedido de E/S o una señal).
• Listo (ready): El proceso está listo para ejecutar, solo necesita del
recurso procesador.
• Finalizado (terminated): El proceso finalizó su ejecución.

ESTADOS DE LOS PROCESOS
• Diagrama de estados y transiciones de los procesos.
35/35

TRANSICIONES ENTRE ESTADOS
36/35
▪ Nuevo

– Listo
▪
Al crearse un proceso pasa inmediatamente al estado listo.
Listo 
E–jecutando
En el estado de listo, el proceso solo espera para que se le asigne un
procesador para ejecutar (tener en cuenta que puede existir más de un
procesador en el sistema). Al liberarse un procesador el planificador
(scheduler) selecciona el próximo proceso, según algún criterio
definido, a ejecutar.

37/35

Ejecutando
Listo
Ante una interrupción que se genere, el proceso puede perder el recurso
procesador y pasar al estado de listo. El planificador será el encargado
de seleccionar el próximo proceso a ejecutar.
E
–
jecutando 
Bloqueado
A medida que el proceso ejecuta instrucciones realiza pedidos en distintos
componentes (ej.: genera un pedido de E/S). Teniendo en cuenta que el
pedido puede demorar y, además, si está en un sistema multiprogramado,
el proceso es puesto en una cola de espera hasta que se complete su
pedido. De esta forma, se logra utilizar en forma más eficiente el
procesador.

38/35
▪ Bloqueado

– Listo
Una vez que ocurre el evento que el proceso estaba esperando en la cola
de espera, el proceso es puesto nuevamente en la cola de procesos listos.
▪ Ejecutando 
Te–rminado
Cuando el proceso ejecuta sus última instrucción pasa al estado terminado.
El sistema libera las estructuras que representan al proceso.

BLOQUE DESCRIPTOR DE PROCESO
▪ El proceso es representado, a nivel del sistema operativo, a través del
bloque descriptor de proceso (Process Control Block)
1 /35

40/35
▪ T
odo proceso se describe mediante su estado, nombre, recursos
asignados, información contable, etc.
▪ Para ello se utiliza una estructura de datos que será el operando de las
operaciones sobre procesos, recursos y del planificador (scheduler).
▪ Los campos de esta estructura son:
▪ Estado CPU: El contenido de esta estructura estará indefinido toda vez
que el proceso está en estado ejecutando (puesto que estará almacenado
en la CPU indicada por procesador). Registro de flags.
▪ Procesador: [1..#CPU]: Contendrá el número de CPU que está ejecutando
al proceso (si está en estado ejecutando), sino su valor es indefinido.
▪ Memoria: Describe el espacio virtual y/o real de direccionamiento según la
arquitectura del sistema. Contendrá las reglas de protección de memoria
así como cual es compartida, etc..
▪ Estado del proceso: ejecutando, listo, bloqueado, etc.

41/35
▪ Recursos: Recursos de software (archivos, semáforos, etc.) y
hardware (dispositivos, etc.).
▪ Planificación: Tipo de planificador.
▪ Prioridad: Podrá incluir una prioridad externa de largo aliento, o en su
defecto una prioridad interna dinámica de alcance reducido.
▪ Contabilización: Información contable como ser cantidad de E/S,
fallos de páginas (page faults), consumo de procesador, memoria
utilizada, etc.
▪ Ancestro: Indica quién creó este proceso.
▪ Descendientes: Lista de punteros a PCBs de los hijos de este
proceso.

CREACIÓN DE PROCESOS
42/35
▪ Los procesos de un sistema son creados a partir de otro proceso.
▪ Al creador se le denomina padre y al nuevo proceso hijo. Esto
genera una jerarquía de procesos en el sistema.
▪ En el diseño del sistema operativo se debe decidir, en el momento
de creación de un nuevo proceso, cuales recursos compartirán el
proceso padre e hijo. Las opciones son que compartan todo, algo o
nada.
▪ También se debe determinar que sucede con los hijos cuando
muere el padre. Pueden morir también o cambiar de padre.
▪ Una vez creado el nuevo proceso tendrán un hilo (program counter)
de ejecución propio. El sistema genera un nuevo PCB para el
proceso creado.

• Ej.: UNIX
• UNIX provee el system call fork para la creación de un nuevo
proceso.
• La invocación a esta función le retorna al padre el número de process
id del hijo recién creado y al hijo el valor 0. El hijo comienza su
ejecución en el retorno del fork.
• Además, se provee del system call exec que reemplaza el espacio de
memoria del proceso por uno nuevo
43/35

44/35
int main() {
pid_t pid;
/* crea un nuevo proceso */ pid = fork();
if (pid < 0) { /* error */
fprintf(stderr, "Fork Failed"); exit(-1);
}
if (pid == 0) /* proceso hijo */
execlp("/bin/ls", "ls", NULL);
else { /* padre */ wait(NULL);
printf("Child Complete"); exit(0);
}
}

Sistemas Operativos | Curso 2015 | Procesos 17/35

LISTAS Y COLAS DE PROCESOS
Los procesos, en los distintos estados que tienen, son agrupados en
listas o colas:
▪ Lista de procesos del sistema (job queue): En esta lista están todos los
procesos del sistema. Al crearse un nuevo proceso se agrega el PCB a
esta lista. Cuando el proceso termina su ejecución es borrado.
▪ Cola de procesos listos (ready queue): Esta cola se compondrá de los
procesos QUE estén en estado listo. La estructura de esta cola
dependerá de la estrategia de planificación utilizada.
▪ Cola de espera de dispositivos (device queue): Los procesos que
esperan por un dispositivo de E/S particular son agrupados en una lista
específica al dispositivo. Cada dispositivo de E/S tendrá su cola de
espera.

Diagrama de transición de un proceso entre las colas del sistema.
48/35

CAMBIO DE CONTEXTO
49/35
A la tarea de cambiar un proceso por otro en el procesador se le
denomina cambio de contexto (context switch).
El cambio de contextos entre procesos implica las siguientes tareas:
▪ Salvar el estado del proceso (registros, información de punteros de
memoria) que está ejecutando en su PCB.
▪ Cambiar el estado del proceso que estaba ejecutando al que
corresponda.
▪ Cargar el estado del proceso asignado a la CPU a partir de su PCB.
▪ Cambiar el estado del proceso nuevo a ejecutando.

CAMBIO DE CONTEXTO

COOPERACIÓN ENTRE PROCESOS
51/35
• Procesos concurrentes pueden ejecutar en un entorno aislado (se
debe asegurar la ausencia de interferencias) o, eventualmente,
podrán interactuar cooperando en pos de un objetivo común
compartiendo objetos comunes.
• Es necesario que el sistema operativo brinde unas herramientas
específicas para la comunicación y sincronización entre los
procesos (Inter Process Communication – IPC).
• IPC es una herramienta que permite a los procesos comunicarse y
sincronizarse sin compartir el espacio de direccionamiento en
memoria.
• Hay dos enfoques fundamentales:
• Memoria compartida
• Pasaje de mensajes

THREADS
52/35
Hay aplicaciones donde es necesario utilizar procesos
que compartan recursos en forma concurrente.
IPC brindan una alternativa a nivel de sistema operativo.
Los sistemas operativos modernos están proporcionando
servicios para crear más de un hilo (thread) de ejecución
(control) en un proceso.
Con las nuevas tecnologías multi-core esto se hace algo
necesario para poder sacar mayor provecho al recurso de
procesamiento.
De esta forma, se tiene más de un hilo de ejecución en el
mismo espacio de direccionamiento.

THREADS
53/35
• Un Thread (Hilo) es una unidad básica de utilización de
la CPU consistente en un juego de registros y un
espacio de pila. Es también conocido como proceso
ligero.
• Cada thread contendrá su propio program counter, un
conjunto de registros, un espacio para el stack y su
prioridad.
• Comparten el código, los datos y los recursos con sus
hebras (thread) pares.
• Una tarea (o proceso pesado) está formado ahora por
uno o varios threads.
• Un thread puede pertenecer a una sola tarea.

THREADS
• Todos los recursos, sección de código y datos son compartidos por
los distintos threads de un mismo proceso.
54/35

VENTAJAS DEL USO DE THREADS
55/35
• Compartir recursos: Los threads de un proceso comparten la
memoria y los recursos que utilizan. A diferencia de IPC, no es
necesario acceder al kernel para comunicar o sincronizar los hilos
de ejecución.
• Economía: Es más fácil un cambio de contexto entre threads ya
que no es necesario cambiar el espacio de direccionamiento. A su
vez, es más “liviano” para el sistema operativo crear un thread que
crear un proceso nuevo.
• Utilización de arquitecturas con multiprocesadores: Disponer
de una arquitectura con más de un procesador permite que los
threads de un mismo proceso ejecuten en forma paralela.
• Repuesta: Desarrollar una aplicación con varios hilos de control
(threads) permite tener un mejor tiempo de respuesta.

DESVENTAJA DEL USO DE THREADS
56/35
• Dificulta la programación: Al compartir todo el espacio de
romper el
direccionamiento un thread mal programado puede
funcionamiento del resto de los threads.

THREADS
57/35
▪ Los threads pueden ser implementados tanto a nivel de usuario
como a nivel de sistemas operativo:
▪ Hilos a nivel de usuario (user threads): Son implementados en alguna
librería de usuario. La librería deberá proveer soporte para crear, planificar
y administrar los threads sin soporte del sistema operativo. El sistema
operativo solo reconoce un hilo de ejecución en el proceso.
▪ Hilos a nivel del núcleo (kernel threads): El sistema es quien provee la
creación, planificación y administración de los threads. El sistema
reconoce tantos hilos de ejecución como threads se hayan creado

THREADS
58/35
▪ Ventajas de user threads sobre kernel threads:
• Desarrollo de aplicaciones en sistemas sin soporte a hilo: Se
pueden aprovechar todos los beneficios de programar orientado
utilizando threads. Además se puede portar la aplicación a un
sistema operativo que carezca de la noción de varios hilos de
ejecución.
• Cambio de contexto: El cambio de contexto entre threads de
usuario es más simple ya que no consume el overhead que
tendría en el sistema operativo (system call).
• Planificación independiente: Se puede crear una nueva estrategia
de planificación diferente a la que tenga el sistema operativo.

THREADS
59/35
• La mayoría de los sistemas proveen threads tanto a nivel de
usuario como de sistema operativo.
• De esta forma surgen varios modelos:
• Mx1 (Many-To-One): Varios threads de a nivel de usuario a un único thread
a nivel de sistema.
• 1x1 (One-to-One): Cada thread de usuario se corresponde con un thread
a nivel del núcleo (kernel thread).
• MxN (Many-To-Many): Varios threads a nivel de usuario se corresponde
con varios threads a nivel del núcleo.

Mx1 (Many-to-One)
Este caso se corresponde al de tener los threads implementados a nivel
de usuario.
El sistema solo reconoce un thread de control para el proceso.
Los threads de usuario ejecutarán cuando estén asignados al kernel
thread del proceso (tarea llevada a cabo por el planificador a nivel de
usuario) y, además, a este le asigne la CPU el planificador del sistema
operativo.
60/35

1x1 (One-to-One)
Cada thread que es creado a nivel de usuario se genera un nuevo thread
a nivel de sistema que estará asociado mientras exista.
El sistema reconoce todos los threads a nivel de usuario y son planificados
independientemente. En este caso no hay planificador a nivel de usuario.
61/35

MxN (Many-to-Many)
• Cada proceso tiene asignado un conjunto de kernel threads independiente
de los threads a nivel de usuario que el proceso haya creado.
• El planificador a nivel de usuario asigna los threads en los kernel threads.
• El planificador de sistema solo reconoce los kernel threads.
62/35

Formando líderes para la construcción
de un nuevo país en paz

Estructura y Procesos de un SO

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Estructura y Procesos de un SO

Similar a Estructura y Procesos de un SO (20)

Más de Richard Eliseo Mendoza Gafaro

Más de Richard Eliseo Mendoza Gafaro (20)

Último

Último (20)

Estructura y Procesos de un SO