Importante

Sistemas Operativos
Raymundo Marcial Romero Jose

J.R.Marcial@cs.bham.ac.uk
Clase Numero 1 p.1/104
Procesos y subprocesos
Todas las computadoras modernas pueden hacer varias cosas al mismo tiempo. En un sistema de multiprogramacin, la CPU tambin cambia de un programa a otro, ejecutando cada uno durante decenas o centenas de milisegundos. Para las personas es difcil dar seguimiento a varias actividades en paralelo Los diseadores de s.o. han desarrollado un modelo conceptual (procesos secuenciales) que facilita tratar con el paralelismo. Este modelo, sus usos y algunas de sus consecuencias se exploraran en esta seccin.
El modelo de procesos
Todo el software ejecutable de la computadora, a veces incluye el s.o., se organiza en varios procesos secuenciales, o simplemente procesos. Un procese es un programa en ejecucin, e incluye los valores que tienen el contador de programa, los registros y las variables. En lo conceptual, cada proceso tiene su propia CPU virtual. En la realidad, la verdadera CPU cambia en forma continua de un proceso a otro. Para entender el sistema es mucho ms fcil pensar que hay un conjunto de procesos que se ejecutan en (pseudo) paralelo, que tratar de comprender la manera en que la CPU cambia de un programa a otro.
La rpida comutacin se denomina multiprogramacin.
Un contador de programa A B Conmutacin de procesos
C D
Figure 1: Multiprogramacin de cuatro programas

En la siguiente gura se muestran cuatro procesos, cada uno con su propio ujo de control (es decir, su propio contador lgico de programa) y ejecutndose de manera independiente.
Cuatro contadores de programa
En la siguiente gura se muestran cuatro procesos, cada uno con su propio ujo de control (es decir, su propio contador lgico de programa) y ejecutndose de manera independiente. Desde luego, slo hay un contador fsico de programa, as que al ejecutarse cada proceso, su contador lgico de programa se carga en el contador de programa real.
En la siguiente gura se muestran cuatro procesos, cada uno con su propio ujo de control (es decir, su propio contador lgico de programa) y ejecutndose de manera independiente. Desde luego, slo hay un contador fsico de programa, as que al ejecutarse cada proceso, su contador lgico de programa se carga en el contador de programa real. Cuando termina provisionalmente, el contador fsico de programa se guarda en el contador lgico de programa del proceso, en la memoria.
En la siguiente gura se muestra que si se observa durante suciente tiempo, todos los procesos han avanzado, pero en un instante dado slo se ejecuta un proceso en realidad.
Procesos
C B A
Tiempo
El modelo de proceso
Con la CPU conmutando entre procesos, la rapidez con que un proceso efecta sus operaciones no ser uniforme y es probable que ni siquiera sea reproducible si los mismos procesos se ejecutan otra vez.
Con la CPU conmutando entre procesos, la rapidez con que un proceso efecta sus operaciones no ser uniforme y es probable que ni siquiera sea reproducible si los mismos procesos se ejecutan otra vez. Los procesos no deben programarse con supuestos acerca del tiempo.
Con la CPU conmutando entre procesos, la rapidez con que un proceso efecta sus operaciones no ser uniforme y es probable que ni siquiera sea reproducible si los mismos procesos se ejecutan otra vez. Los procesos no deben programarse con supuestos acerca del tiempo. Ejemplo: considere un proceso de E/S que pone en marcha una cinta para restaurar archivos respaldados, ejecuta un ciclo inactivo 10,000 veces para permitirle alcanzar la velocidad de operacin y luego emite un comando para leer el primer registro.
Si la CPU decide cambiar a otro proceso durante un ciclo inactivo, el proceso de cinta podra no ejecutarse otra vez sino hasta que el primer registro pase bajo la cabeza de lectura.
Si la CPU decide cambiar a otro proceso durante un ciclo inactivo, el proceso de cinta podra no ejecutarse otra vez sino hasta que el primer registro pase bajo la cabeza de lectura. En estas situaciones, es preciso tomar medidas especiales. Es decir tener una jerarqua de procesos.
Si la CPU decide cambiar a otro proceso durante un ciclo inactivo, el proceso de cinta podra no ejecutarse otra vez sino hasta que el primer registro pase bajo la cabeza de lectura. En estas situaciones, es preciso tomar medidas especiales. Es decir tener una jerarqua de procesos. La idea clave es que un proceso es una actividad de algn tipo: tiene un programa, entradas salidas y un estado.
Si la CPU decide cambiar a otro proceso durante un ciclo inactivo, el proceso de cinta podra no ejecutarse otra vez sino hasta que el primer registro pase bajo la cabeza de lectura. En estas situaciones, es preciso tomar medidas especiales. Es decir tener una jerarqua de procesos. La idea clave es que un proceso es una actividad de algn tipo: tiene un programa, entradas salidas y un estado. Varios procesos pueden compartir un solo procesador, y se usa algn algoritmo de calendarizacin para determinar cundo hay que dejar de trabajar en un proceso y atender otro.
Creacin de procesos
Los s.o. requieren de alguna forma de comprobar que existan todos los procesos necesarios. En sistemas sencillos, podra ser factible hacer que todos los procesos que alguna vez se necesiten estn presentes cuando el sistema arranque. En los sistemas de propsito general hace falta algn mecanismo para crear y terminar procesos segn se necesite durante la operacin.
Creacin de procesos
Hay cuatro sucesos principales que causan la creacin de procesos: 1. Inicializacin del sistema 2. Ejecucin de una llamada al sistema para crear procesos por parte de un proceso en ejecucin. 3. Solicitud de un usuario para crear un proceso 4. Inicio de un trabajo por lotes.
Creacin de procesos
Cuando se arranca un s.o., por lo regular se crean varios procesos. Algunos son de primer plano; es decir, procesos que interactan con usuarios y trabajan para ellos. Otros son procesos de segundo plano que no estn asociados con un usuario en particular, sino que tienen una funcin especca. Por ejemplo: podra disearse un proceso de segundo plano que acepte el correo electrnico entrante, este proceso quedara inactivo casi todo el da pero entrara en accin repentinamente si llega algn mensaje. Los procesos de segundo plano se llaman demonios (daemons)
Creacin de procesos
Adems de los procesos que se crean en el momento de arranque, es posible crear procesos posteriormente. Es comn que un proceso en ejecucin emita llamadas al sistema para crear uno o ms procesos que le ayuden a su labor. La creacin de procesos tiene gran utilidad cuando el trabajo a realizarse puede formularse con facilidad a partir de varios procesos relacionados. En un multiprocesador el trabajo tambin se realizar ms rpido si permite que cada proceso se ejecute en una CPU distinta.
Creacin de procesos
En los sistemas interactivos, los usuarios pueden iniciar un programa tecleando un comando o haciendo (doble) clic en el icono. En UNIX, el proceso nuevo se apropia de la ventana en la que se inici. En Windows, no tiene una ventana, pero puede crear una (o ms) y casi todos lo hacen. Con el ratn un usuario puede seleccionar una ventana e interactuar con el proceso; por ejemplo proporcionando entradas cuando lo necesite. La ltima situacin en la que se crean procesos slo es vlida en los sistemas por lotes de las mainframes grandes.
Creacin de procesos
En todos estos casos un proceso se crea haciendo que un proceso existente ejecute una llamada al sistema para crear procesos. Dicho proceso puede ser de: usuario, de sistema o de administrador de lotes. Lo que hace es ejecutar una llamada al sistema para crear el proceso; esta llamada le ordena al s.o. crear un proceso e indica, de manera directa o indirecta, cul programa debe ejecutar en l. En UNIX: fork crea un proceso. Por lo regular el proceso hijo ejecuta despus execve o una llamada al sistema similar para modicar su imagen y ejecutar un programa nuevo.
Creacin de procesos
En Windows, una sola llamada de Win32, CreateProcess, se encarga tanto de crear procesos como de cargar el programa correcto en el proceso nuevo. Esta llamada tiene 10 parmetros Adems de CreateProcess, Win32 tiene cerca de 100 funciones ms para administrar y sincronizar procesos, y actividades relacionadas. Tanto en UNIX como en Windows, una vez que se crea un proceso, tanto el padre como el hijo tienen sus propios espacios de direcciones distintos. En UNIX, el espacio de direcciones inicial del hijo es una copia del que tiene el padre, pero son dos espacios diferentes. En Windows son distintos desde el principio.
Terminacin de procesos
Una de las siguientes razones causa por lo regular la terminacin de un proceso: 1. Terminacin normal (voluntaria). 2. Terminacin por error (voluntaria). 3. Error fatal (involuntaria). 4. Terminado por otro proceso (involuntaria).
La mayora de los procesos termina porque ya realiz su trabajo. Una vez que un compilador ha compilado el programa que se le aliment, ejecuta una llamada para indicar al s.o. que ya termin. Esta llamada es exit en UNIX y ExitProcess en Windows. Los programas por pantalla tambin suelen terminar en forma voluntaria.
El segundo motivo para terminar es que el proceso descubra un error fatal. Por ejemplo, si un usuario ejecuta el comando cc algo.c para compilar el programa algo.c y no existe tal archivo, el compilador simplemente terminar. El tercer motivo es un error causado por el proceso, a menudo debido a un defecto del programa. Ejemplos de esto son: ejecutar una instruccin no permitida, hacer referencia a memoria que no existe y dividir entre cero. En algunos sistemas (UNIX), un proceso puede indicar al s.o. que desea manejar ciertos errores l mismo. Si se presenta algn error, se enva una seal (interrupcin) al proceso, en lugar de terminarlo.
La cuarta razn por la que un proceso podra terminar es que otro proceso ejecute una llamada para pedirle al s.o. que termine el proceso en cuestin. En UNIX la llamada es kill. En Windows es TerminateProcess. En ambos casos el proceso que solicita la llamada debe contar con cierta autorizacin. En algunos sistemas, cuando un proceso termina (de cualquier forma) todos los procesos que cre tambin terminan de inmediato. Sin embargo, ni UNIX ni Windows funcionan as.
Jerarquas de procesos
Un proceso slo tiene un padre (y cero uno o ms hijos). En UNIX, un proceso, todos sus hijos y sus dems descendientes forman un grupo de procesos. Cuando un usuario enva una seal desde el teclado, sta se entrega a todos los miembros del grupo de procesos asociados en ese momento con el teclado. De manera individual, cada proceso puede atrapar la seal, ignorarla o realizar la accin predeterminada, que es nalizar a causa de la seal.
Ejemplo: como se prepara UNIX al principio cuando se le pone en marcha: Un proceso especial, llamado init, est presente en la imagen de arranque. Cuando dicho proceso empieza a ejecutarse, lee un archivo que indica cuntas terminales hay y genera un proceso nuevo por cada una. Estos procesos esperan a que alguien inicie sesin. Si hay un inicio de sesin exitoso el proceso login ejecuta un shell para aceptar comandos. Estos podrian generar ms comandos y as en forma sucesiva.
En contraste, Windows no tiene el concepto de jerarqua de procesos. Todos los procesos son iguales. Lo nico que podra parecer a una jerarqua de procesos es cuando se crea un proceso: el padre recibe una "cha" especial (llamada identicador) que le sirve para controlar al hijo. Sin embargo, el padre esta en la libertad de transferir la cha a algn otro proceso, deshaciendo as la jerarqua.
Estados de procesos
Es comn que un proceso tenga que interactuar con otros procesos (an cuandoo tiene su propio contador de programas y estado interno). Un proceso podra generar salida que otro utilice como entrada. Ejemplo cat parte1 parte2 parte3 | grep rbol. Los tres estados en que puede estar un proceso son los siguientes: En ejecucin (en realidad, usando la CPU en ese instante). Listo (puede ejecutarse, detenido de forma temporal para permitir que se ejecute otro proceso). Bloqueado (no puede ejecutarse mientras no ocurra cierto suceso externo).
Estado de procesos
En ejecucin
1 3
Bloqueado Listo
1. El proceso se bloquea para esperar entrada 2. El calendarizador escoge otro proceso 3. El calendarizador escoge este proceso 4. Ya hay entrada disponible
Estado de procesos
Los primeros dos estados son similares desde el punto de vista lgico. En ambos casos el programa est dispuesto a ejecutarse, slo que en el segundo por el momento no hay CPU disponible para l. El tercer estado es diferente de los anteriores en cuanto que el proceso no puede ejecutarse, aunque la CPU no tenga nada ms que hacer. Utilizando el sistema de procesos, ser mucho mas fcil entender lo que sucede dentro del sistema.
Estado de procesos
Algunos procesos ejecutan programas que, a su vez, ejecutan comandos tecleados por un usuario. Otros forman parte del sistema y se encargan de tareas como atender solicitudes de servicio de archivos u ocuparse de los pormenores de la operacin de una unidad de disco o cinta. En vez de pensar en interrupciones, podemos pensar en procesos de usuario, procesos de disco, etc, que se bloquean cuando esperan que suceda algo. Este punto de vista da pie al siguiente modelo:
Estado de procesos
Procesos
...
n-2
n-1
Calendarizador
La capa ms baja de un sistema operativo con estructura de procesos maneja las interrupciones y la calendarizacin. Arriba de ella estan los procesos secuenciales.
Implementacin de procesos
Para implementar el modelo de procesos, el s.o. mantiene una tabla (un arreglo de estructura), llamada tabla de procesos, con una entrada por proceso. La entrada contiene informacin acerca del estado del proceso, su contador de programa, apuntador a la pila, asignacin de memoria, estado de sus archivos abiertos, informacin contable y de calendarizacin entre otras cosas.
Administracin de procesos Registros Contador de programa Palabra de estado del programa Apunte de pila Estado del proceso Prioridad Parametros de Calendarizacion ID de proceso Proceso padre Grupo de procesos Seales Hora de inicio del proceso Tiempo de CPU consumido Tiempo de CPU de los hijos Hora de la siguiente alarma Administracin de memoria Apuntador a segmento de texto Apuntador a segmento de datos Apuntador a segmento de pila Administracion de archivos Directorio raz Directorio de trabajo Descriptores de archivo ID de usuario ID de grupo
La forma en que se mantiene la ilusin de mltiples procesos secuenciales en una mquina conn una CPU y muchos dispositivos de E/S es la siguiente: Cada clase de dispositivos de E/S est asociada con una posicin de memoria, llamada vector de interrupcin. ste contiene la direccin del procedimiento de servicio de interrupcin. Supongamos que el proceso de usuario 3 se est ejecutando cuando ocurre una interrupcin de disco.
1. El hardware mete el contador de programa, en la pila, etc. 2. El hardware carga un nuevo contador de programa tomndolo del vector de interrupciones. 3. Un procedimiento en ensamblador guarda registros. 4. Un procedimiento en ensamblador crea la nueva pila. 5. Se ejecuta el servicio de interrupciones en C (que suele leer entradas y ponerlas en un bfer). 6. El calendarizador decide qu programa ejecutar ahora. 7. El procedimiento en C regresa el cdigo ensamblador. 8. Un procedimiento en ensamblador arranca el nuevo proceso actual.
subprocesos
En los s.o. tradicionales cada proceso tiene un espacio de direcciones y un solo subproceso de control. Sin embargo, hay situaciones en las que es deseable tener varios subprocesos de control en el mismo espacio de direcciones, operando de forma seudoparalela, como si fueran procesos individuales (salvo por el espacio de direcciones compartido).
El modelo de subproceso
El modelo de proceso descrito hasta ahora se basa en dos conceptos independientes: agrupamiento de recursos y ejecucin. A veces es til separalos, y es aqu donde entran los subprocesos. Un proceso se puede considerar como una forma de agrupar recursos relacionados. Un proceso tiene un espacio de direcciones que contiene lo datos y el texto del programa, as como otros recursos, que podran incluir archivos abiertos, procesos hijos, alarmas pendientes, etc. Al juntar todas estas cosas en forma de un proceso se les puede administrar con ms facilidad.
El otro concepto que tiene un proceso es un subproceso en ejecucin o simplemente subproceso. ste tiene un contador de programa que indica cul instruccin se ejecutar a continuacin, tiene registros, que contienen sus variables de trabajo actuales, y tiene una pila, que contiene el historial de ejecucin. Aunque un subproceso debe ejecutarse en algn proceso, el subproceso y su proceso son conceptos distintos que pueden tratarse aparte. Los procesos sirven para agrupar recursos; los subprocesos son las entidades que se calendarizan para ejecutarse en la CPU.
Los subprocesos aportan al modelo de procesos la posibilidad de que haya varias ejecuciones en el mismo entorno de un proceso, en gran medida independientes una de otra. Tener mltiples subprocesos ejecutndose en paralelo en un proceso es anlogo a tener mltiples procesos ejecutndose en paralelo en una computadora. En el primer caso, los subprocesos comparten un espacio de direcciones, archivos abiertos y otros recursos. En el segundo caso, los procesos comparten una memoria fsica, discos impresora y otros recursos.
Debido a que los subprocesos tienen algunas propiedades de los procesos, a veces se les llama procesos ligeros. El termino mltiples procesos se emplea para describir la situacin en la que se permite varios subprocesos en el mismo proceso.
Proceso 1 Proceso 1 Proceso 1 Proceso
Espacio de usuario
subproceso Espacio de kernel
subproceso
kernel
kernel
Cuando un proceso con mltiples subprocesos se ejecuta en un sistema con una sola CPU, los subprocesos se turnan para ejectarse. Los distintos subprocesos de un proceso no son tan independientes como lo son los procesos distintos. Todos los subprocesos tienen el mismo espacio de direcciones, lo que implica que comparten las mismas variables globales. Dado que cada subproceso puede tener acceso a todas las direcciones de memoria del espacio de direcciones del proceso, un subproceso podra leer, modicar o borrar por completo la pila de otro subproceso. No extiste proteccin entre los subprocesos porque 1)es imposible, y 2)no debera ser necesaria.
Adems de compartir el mismo espacio de direcciones, todos los subprocesos comparten el mismo conjunto de archivos abiertos, procesos hijos, alarmas, seales, etc.
Elementos por proceso Espacio de direcciones Variables globales Archivos abiertos Procesos hijo Alarmas pendientes Seales y manejadores de seales Informacin contable
Elementos por subproceso Contador de programa Registros Pila Estado
Un subproceso puede estar en uno de varios estados: en ejecucin, bloqueado, listo o terminado. Es importante tomar en cuenta que cada subproceso tiene su propia pila. La pila contiene un marco por cada procedimiento invocado del cual todava no se ha regresado. El marco contiene las variables locales del procedimiento y la direccin de retorno que se usar cuando la llamada del procedimiento termine. Cada subproceso invocar procedimientos distintos y, por tanto, tendr un historial de ejecucin distinto. Por eso cada subproceso necesita su propia pila.
Los procesos por lo general empiezan con un solo subproceso. Este puede crear subprocesos nuevos invocando a un procedimiento de biblioteca, por ejemplo, thread_create. Por lo general, un parmetro de thread_create especica el nombre de un procedimiento que el nuevo subproceso ejecutar. No es necesario especicar algo acerca del espacio de direcciones del nuevo subproceso, pues ste se ejecuta en forma automtica en el espacio de direcciones del subproceso que lo cre. Cuando un subproceso termina, puede salir invocando a un procedimiento de biblioteca, digamos thread_exit.
En algunos sistemas, un subproceso puede esperar a que otro termine; para ello, invocara un procedimiento como thread_wait. Otra llamada comn es thread_yield, que permite a un subproceso conceder en forma voluntaria la CPU a otro para que se ejecute. Esta llamada es importante ya que no existe una interrupcin de reloj que obligue a compartir el tiempo, como en el caso de los procesos. Aunque los subprocesos a menudo son tiles, introducen varias complicaciones en el modelo de programacin.
Si el proceso padre tiene mltiples subprocesos, el hijo tambin deber tenerlos? De lo contrario es posible que no funcione de forma correcta. Si el proceso hijo obtiene tantos subprocesos como el padre, que suceder si un subprocesoo del padre estaba bloqueado por una llamada read, digamos, del teclado? Qu sucede si un subproceso cierra un archivo mientras otro todava lo esta leyendo? Supongamos que un subproceso se da cuenta de que no hay suciente memoria y empieza a asignar ms. Antes de que termine de hacerlo, ocurre una conmutacin de subprocesos y el nuevo se da cuenta de lo mismo y empieza a asignar memoria.
Uso de subproceso
Por que podran ser utiles los subprocesos? El motivo principal es que en diversas aplicaciones, se estn realizando varias actividades al mismo tiempo, por lo que algunas de ellas podran bloquearse de vez en cuando. Al descomponer tal aplicacin en mltiples subprocesos secuenciales que se ejecuten casi en paralelo, se simplica el modelo de programacin. El elemento nuevo (a diferencia de los procesos) es la posibilidad de que las entidades paralelas compartan un espacio de direcciones y todos sus datos.
Uso de subproceso
Un segundo argumento es que, al no estar enlazados con recursos, son ms fciles de crear y destruir que los procesos. Un tercer motivo tambin se relaciona con el desempeo. Los subprocesos no mejoran el desempeo cuando todos usan intensamente la CPU, pero si se realiza una cantidad considerable tanto de cmputo como de E/S, los subprocesos permiten traslapar estas actividades y as acelerar la aplicacin. Por ltimo son tiles en sistemas con mltiples CPUs, en los que es posible un verdadero paralelismo.
Uso de subproceso
Ejemplo: Un procesador de texto: La mayora muestran en la pantalla el documento que se est creando con el formato exacto con el que aparecer en la pagina impresa. Supongamos que el usuario esta escribiendo un libro. Desde el punto de vista del autor, es ms fcil tener todo el libro en un solo archivo para facilitar la bsqueda de temas, efectuar sustituciones globales, etc. Como alternativa, cada captulo podra ser un archivo aparte. Sin embargo sera una molestia en caso de que fuera necesario efectuar modicaciones globales a todo el libro.
Uso de subproceso
Considere que sucede cuando el usuario de repente borra una oracin de la pgina 1 de un documento de 800 pginas Despus de revisar la pgina modicada, el usuario desea efectuar otro cambio en la pgina 600 y teclea un comando para ir a esa pgina. ste se vera obligado a reformatear todo el libro hasta la pagina 600, por que no sabr cul es la primera linea de la pgina 600, en tanto no haya procesado todas las pginas anteriores. Podra pasar un tiempo apreciable antes de poder mostrar la pgina 600, lo cual no har muy feliz al usuario. Aqu es donde podran ayudar los subprocesos.
Uso de subproceso
Supongamos que el procesador de textos est escrito como un programa de dos subprocesos. Un subproceso interacta con el usuario y el otro se encarga de reformatear en segundo plano. Tan pronto como se borra la oracin de la pgina 1, el subproceso interactivo le dice al subproceso de reformateo que ajuste el formato de todo el libro. Mientras tanto, el subproceso interactivo estar al tanto del teclado y del ratn y responder a comandos sencillos, como moverse en la pgina 1, mientras el otro est calculando frenticamente en segundo plano.
Uso de subproceso
Por que no adir un tercer subproceso que se encargue de las copias de respaldo? Como funcionara. Debe ser obvio que tener tres procesos no funcionara en este caso por que los tres subprocesos necesitan trabajar con el documento. Al tener 3 subprocesos en lugar de 3 procesos, se comparte la misma memoria y todos los subprocesos tienen acceso al documento que se esta editando. Otros ejemplos donde los subprocesos son tiles son: Hoja de clculo y un servidor para un sitio web.
Uso de subproceso
Supongamos que no es posible utilizar multiples subprocesos pero los diseadores del sistema consideran intolerable la baja en el desempeo debido al uso de un solo subproceso. Si se cuenta con una versin no bloqueadora de la llamada read, puede adoptarse un tercer enfoque. Cuando llega una solicitud, la examina el nico subproceso que hay. Si se puede atender con una pgina del cach, perfecto; sino se inicia una operacin de disco no bloqueadora. El servidor registra el estado de la solicitud en una tabla y luego obtiene el siguiente evento, que podra ser una nueva solicitud de trabajo o una respuesta del disco relacionado con una operacin anterior
Uso de subproceso
Si se trata de trabajo nuevo, se inicia. Si es una respuesta del disco, se saca la informacin pertinente de la tabla y se procesa la respuesta. Con E/S de disco no bloqueadora, es probable que la respuesta consistir en una seal o una interrupcin. En este diseo se pierde el modelo de "procesos secuenciales" que tenamos en los dos primeros casos. Se vuelve necesario guardar de manera explcita el estado del clculo en la tabla y restaurarlo de ella cada vez que el servidor deja de trabajar con la solicitud.
Uso de subproceso
En efecto, estamos simulando los subprocesos y sus pilas de la forma difcil. Un diseo as en la que cada clculo tiene un estado guardado y existe algn conjunto de eventos que pueden modicar el estado, se denomina mquina de estados nitos.
Modelo Subprocesos Proceso de un solo subproceso Mquina de estados nitos Caractersticas Paralelismo, llamadas bloqueadoras al sistema Sin paralelismo, llamadas bloqueadoras al sistema interrupciones
Paralelismo, llamadas no bloqueadoras al sistema, interrupcio
Implementacin de subprocesos en espacio de usuario

Hay dos formas de implementacin de subprocesos: en espacio de usuario y en el kernel. La desicin a dado pie a cierta controversia y tambin existe una implementacin hbrida. Las ventajas de colocar el sistema de subprocesos en espacio de usuario son las siguientes: Puede implementarse un sistema de subprocesos en el nivel de usuario en un s.o. que no maneje subprocesos. Todos los s.o. pertenecan a esta categora y todav subsisten algunos.
Proceso
Subproceso
Espacio de usuario
Espacio de kernel
kernel
Sistema de tiempo de ejecucin
Tabla de subprocesos
Tabla de procesos

Permitir que cada proceso tenga su propio algoritmo de calendarizacin personalizado. En algunas aplicaciones, como las que tiene un subproceso recolector de basura, es una ventaja no tener que preocuparse porque un subproceso vaya a detenerse en un momento no conveniente. Adems, es ms fcil aumentar se escala, pues los procesos de kernel siempre requieren espacio de tabla y de pila de kernel. A pesar de su buen desempeo, los sistemas de subprocesos en el nivel de usuario tienen problemas importantes.

El principal es la manera en que se implementan las llamadas bloqueadoras al sistema. Supongamos que algn subproceso lee del teclado antes de que se oprima alguna tecla. No es posible permitirle al subproceso que emite en realidad la llamada al sistema, pues eso detentra a todos los subprocesos. Uno de los principales objetivos de tener subprocesos es precisamente que todos puedan usar llamadas bloqueadoras, pero sin afectarse.

Una alternativa en los casos en que es posible saber con antelacin si se bloquear o no una llamada lo ofrecen algunas versiones de UNIX. Cuentan con una llamada al sistema llamada select, que indica si una llamada read propuesta se bloquear o no. Otro problema es el de fallos de pgina. Las computadoras pueden organizarse de tal manera que no todo el programa est en memoria principal a la vez Si el programa salta a una intruccin que no est en la memoria, ocurre un fallo de pgina y el s.o. trae la instruccin faltante del disco.

El proceso se bloquea mientras se localiza la instruccin necesaria. Si un subproceso causa un fallo de pgina, el kernel, que ni siquiera sabe de la existencia de los subprocesos, bloquear todo el proceso hasta que termine la E/S de disco, aunque otros subprocesos puedan seguir ejecutandose. Otro problema es que si un subproceso comienza a ejecutarse, ningn otro subproceso de ese proceso podr ejecutarse si el primero no cede de manera voluntaria la CPU.
Implementacin de subprocesos en espacio de kernel

En este caso el kernel esta enterado de la existencia de subprocesos y los puede administrar. No se necesita un sistema de tiempo de ejecucin en cada uno.
Proceso Subproceso
kernel
Tabla de proceso
Tabla de subproceso

Cuando un subproceso quiere crear o destruir otro subproceso, emite una llamada al kernel, que se encarga de crearlo o destruirlo de su tabla de subprocesos. La tabla de subprocesos del kernel contiene los registros, el estado, y dems informacin de cada subproceso. Todas las llamadas que podran bloquear a un subproceso se implementan como llamadas al sistema y tienen un costo mucho mayor que las llamadas a procedimientos de un sistema de tiempo de ejecucin.

Cuando un subproceso se bloquea, el kernel a criterio propio, puede ejecutar otro subproceso del mismo proceso (si hay uno listo) o alguno de otro proceso. Debido al costo mayor de crear y destruir subprocesos en el kernel, algunos sistemas adoptan un enfoque de reciclado de subprocesos. Cuando un subproceso se destruye, se marca como no ejecutable, pero sus estructuras de datos en el kernel se mantienen. Cuando es necesario crear un subproceso, se reactiva uno antiguo, ahorrando algo de procesamiento extra. Los subprocesos de kernel no necesitan nuevas llamadas al sistema no bloqueadoras

Si un subproceso de un proceso causa un fallo de pgina, el kernel puede vericar con facilidad si el proceso tiene algn otro subproceso ejecutable, y en su caso, ejecutar uno de ellos mientras espera que la pgina necesaria llegue al disco. Su principal desventaja es el costo elevado de una llamada al sistema. Si las operaciones de subprocesos (creacin, terminacin, etc.) son usuales, se requerir mucho procesamiento extra.
Implementacin hbridas
Una forma de combinar los anteriores es usar subprocesos en el nivel de kernel y luego multiplexar subprocesos en el nivel de usuario en uno de los subprocesos de kernel, o en todos.
Mltiples subprocesos de usuario en un subproceso de kernel
Subproceso de kernel kernel

Actividades del Calendarizador

Pendiente
Subprocesos emergentes
Pendiente
Comunicacin entre procesos

Hay tres aspectos que cuidar: 1. Cmo puede un proceso pasar informacin a otro 2. Asegurarse de que dos o ms procesos no se estorben al realizar actividades cruciales (supongamos que dos procesos tratan de apoderarse del tlimo megabyte de memoria). 3. El ordenamiento correcto cuando existen dependencias: si el proceso A produce datos y el proceso B los imprime, B tendr que esperar hasta que A haya producido algunos datos antes de comenzar a imprimir. 4. Los puntos 2 y 3 tambin se aplican a los subprocesos. 5. El 1ro - la transferencia de informacin - es fcil para los subprocesos porque comparten un solo espacio de
Condiciones de competencia
En algunos s.o., procesos que estn colaborando podran compartir un rea de almacenamiento que ambos pueden leer y escribir. El almacenamiento compartido podra ser la memoria principal, o bien, ser un archivo compartido. La ubicacin de la memoria compartida no altera la naturaleza de la comunicacin ni los problemas que se presentan. Ejemplo: el spooler de impresin. Cuando un proceso quiere imprimir un archivo, coloca su nombre en un directorio de spooler especial. Otro proceso, el demonio de impresora, ve en forma peridica si hay algn archivo por imprimir y , si lo hay, lo imprime y borra su nombre del directorio.
Condiciones de competencia
Imaginemos que nuestro directorio de spooler tiene un gran nmero de ranuras, nmeradas 0, 1, 2, . . . , cada una de las cuales puede contener un nombre de archivo. Imaginemos que hay dos variables compartidas: out que apunta al siguiente archivo que se imprimir, e in, que apunta a la siguiente ranura desocupada del directorio.
4 5 Proceso A 6 in = 7 7 Proceso B
out = 4
Regiones Crticas
Cmo evitamos las condiciones de competencia? La clave es impedir que dos o ms procesos lean o escriban los datos compartidos al mismo tiempo. En otras palabras de necesita exclusin mutua, es decir, alguna forma de asegurarnos de que si un proceso est utilizando una variable compartida o un archivo compartido, los dems mo podrn hacer lo mismo. La decisin de qu operaciones primitivas son apropiadas para lograr la exclusin mutua es una importante cuestin de diseo en cualquier s.o.
Regiones Crticas
La parte del programa en la que se tiene acceso a la memoria compartida se denomina regin crtica o seccin crtica. Si pudieramos organizar las cosas de tal manera que dos procesos nunca estn al mismo tiempo en su regin crtica se evitara la competencia. Se necesitan cuatro condiciones para tener una buena solucin.
Regiones Crticas
1. Dos procesos no pueden estar al mismo tiempo dentro de sus regiones crticas. 2. No pueden hacerse suposiciones sobre las velocidades ni el nmero de las CPUs. 3. Ningn proceso que se est ejecutando afuera de su regin crtica puede bloquear a otros procesos. 4. Ningn proceso deber tener que esperar de manera indenida para entrar a su regin crtica.
Regiones Crticas
A entra a su regin crtica A sale de su regin crtica
Proceso A B intenta entrar B entra en su regin en su regin crtica crtica B bloqueado T1 T2 T3 T4 B sale de su regin crtica
Proceso B
Exclusin mutua con espera activa

Examinaremos diversas propuestas para lograr la exclusin mutua, de modo que mientras un proceso est actualizando la memoria compartida en su regin crtica, ningn otro proceso entre en su propia regin crtica y cause problemas. Inabilitacin de interrupciones La solucin ms sencilla es hacer que cada proceso inhabilite todas las interrupciones inmediatamente despus de ingresar en su regin crtica y las vuela a habilitar justo antes de salir. Con las interrupciones inhabilitadas, no puede haber interrupciones de reloj. Por lo tanto la CPU no se cambiara a otro porceso.
Inabilitacin de interrupciones
Una vez que un proceso haya inhabilitado las interrupciones, podr examinar y actualizar la memoria compartida sin temor a la intromisin de otro proceso. Este enfoque es poco atractivo ya que no es prudente conferir a los procesos de usuario la capacidad de inhabilitar todas las interrupciones. Supongamos que uno de ellos lo hace y nunca vuelve a activarlas, eso podra acabar con el sistema. Adems, si el sistema es un multiprocesador, la inhabilitacin de interrupciones slo afectar a la CPU que ejecut la instruccin disable. Las dems seguiran operando en forma normal y podrn tener acceso a la memoria compartida.
Inabilitacin de interrupciones
Muchas veces es conveniente que el kernel mismo inhabilite las interrupciones durante unas cuantas instrucciones, mientras actualiza variables o listas. Por ejemplo, si ocurriera una interrupcin en un momento en que la lista de procesos listos se encuentra en un estado inconsistente, podran presentarse condiciones de competencia. Conclusin: inhabilitar las interrupciones a menudo es una tcnica til dentro del s.o. mismo, pero no es apropiado como mecanismo general de exclusin mutua para procesos de usuario.
Variables de Bloqueo
Esta es un intento de solucin en software. Consideraremos el uso de una sola variable compartida (de bloqueo) que inicialmente es 0. Cuando un proceso quiere entrar a su regin crtica, primero prueba el bloqueo. Si ste es 0, el proceso lo establece a 1 y entra en la regin crtica.
Si el bloqueo ya es 1, el proceso espera hasta que cambie a 0. Por desgracia, esta idea contiene exactamente el mismo defecto que vimos en el directorio spooler. Supongamos que un proceso lee el bloqueo y ve que es 0. Antes de que puede establecerlo a 1, se calendariza otro proceso, el cual se ejecuta y establece el bloqueo a.
Cuando el primer proceso vuelve a ejecutarse, tambin establecer a 1 el bloqueo, y dos procesos estarn en su regin crtica al mismo tiempo. Se podra pensar que este problema se puede resolver si primero se lee el valor del bloqueo y luego vuelve a vericarse, inmediatamente antes de almacenarlo, pero esto de nada serve. La competencia se presenta ahora si el segundo proceso modica el bloqueo justo despus de que el segundo termina su segunda vericacin.
Alternancia estricta
Un tercer enfoque se muestra a continuacin.
while(T RU E ) { while (turno! = 0) / ciclo /; region critica(); turno = 1; region no critica(); } while(T RU E ) { while (turno! = 1) / ciclo /; region critica(); turno = 0; region no critica(); }
La variable entera turno, que al principio es 0, indica a quin le corresponde entrar en la regin crtica y examinar o actualizar la memoria compartida. Al principio el proceso 0 examina turno, ve que es 0, y por lo tanto entra en su regin crtica. El proceso 1 tambin ve que es 0 y por lo tanto, da vueltas en un ciclo corto probando en forma continua turno para detectar cuando cambie a 1. La espera continua de una variable hasta que adquiere un valor se denomina espera activa. En general debe evitarse ya que desperdicia tiempo de CPU. Solo se usa cuando es razonable suponer que la espera ser corta.
Un bloqueo que utiliza espera activa se denomina bloqueo giratorio. Cuando el proceso 0 sale de su regin crtica establece turno a 1, y ello permite al proceso 1 entrar en su regin crtica. Supongamos que el proceso 1 termina rpido su regin crtica, de modo que ambos procesos estn en sus regiones no crticas y turno es 0. Sin embargo turnarse no es buena idea cuando uno de los procesos es mucho ms lento que el otro.
Solucin de Peterson
Combinando la idea de turnarse con la idea de variables de bloqueo y variables de advertencia, un matemtico holands T. Dekker, fue el primero en idear una solucin en software para el problema de la exclusin mutua que no requiere alternancia estricta. Esta puede consultarse en: Dijkstra (1965) En 1981, G. L. Peterson descubri una forma mucho ms sencilla de lograr la exclusin mutua lo que volvi obsoleta la solucin de Dekker. El algortimo consta de dos procedimientos escritos en ANSI C.
Solucin de Peterson
#def ine F ALSE 0 #def ine T RU E 1 #def ine N 2 / nu mero de procesos / int turno; / a quie n le toca? / int interesado[N ]; / todos son inicialmente 0 / void entrar region(int proceso) / proceso es 0 o 1 / { int otro; / numero de otros procesos / otro = 1 proceso; / lo contrario de proceso / interesado[proceso] = T RU E ; / muestra interes / turno = proceso; / establece indicador / while(turno == proceso && interesado[otro] == T RU E ) / instruccion nula / } void salir region(int proceso) / proceso : quien sale / { interesado[proceso] = F ALSE / indica salir de region cirtica / }
Solucin de Peterson
Antes de usar las variables compartidas (es decir, antes de entrar a su regin crtica), cada proceso invoca a entrar_region con su propio nmero de proceso, 0 o 1, como parmetro. Esta llamada lo har que espere si es necesario, hasta que pueda entrar sin peligro. Una vez que haya terminado de usar las variables compartidas, el proceso invocar a salir_region para indicar que ya termin y permitir al otro proceso que entre, si lo desea.
La instruccin TSL
Esta propuesta requiere un poco de ayuda del hardware. Muchas computadoras sobre todo las disenadas pensando en mltiples procesadores, tienen una instruccin TSL RX,BLOQUEO (Test and Set Lock, probar y establecer bloqueo). Lee el contenido de la palabra de memoria bloqueo lo coloca en el registro RX y luego guarda un valor distinto de 0 en la direccin de memoria bloqueo.
La instruccin TSL
Se garantiza que las operaciones de leer la palabra y escribir en ella son individuales: ningn otro procesador puede tener acceso antes de haya terminado de ejecutarse la intruccin. La CPU que ejecuta la instruccin cierra el bus de memoria para impedir que otras CPUs tengan acceso a la memoria antes de que termine. Una variable compartida bloqueo coordina el acceso a la memoria compartida. Cuando bloqueo es 0, cualquier proceso puede establecer a 1 utilizando la instruccin TSL y luego escribir o leer en la memoria compartida. Cuando termina el proceso vuelve a establecer a 0 dicha variable.
La instruccin TSL
Como puede esta instruccin evitar que dos procesos ingresen al mismo tiempo a su regin crtica?
entrar region : T SL REGIST RO, BLOQU EO |copia el registro en el bloqueo y lo establece a 1 CM P REGIST RO, #0 | el bloqueo era cero? JN E entrar region | si no era 0, hab ia bloqueo; por lo tanto realiza un ciclo RET | retorna al invocador; se entro en regio n cr itica salir region : M OV E BLOQU EO, #0 |establece a 0 el bloqueo RET | retorno al invocador
La instruccin TSL
Antes de entrar en su regin crtica, un proceso invoca a entrar_region, que efecta una espera activa hasta que el bloqueo est libre, luego adquiere el bloqueo y lo termina. Despus de la regin crtica, el proceso invoca a salir_region, que coloca un 0 en el bloqueo. Al igual que todas las soluciones basadas en regiones crticas, los procesos deben invocar los procedimientos en los momentos correctos para que el mtodo funcione. Si un proceso hace trampa la exclusin mutua fracasar.
Activar y desactivar
Tanto la solucin de Peterson como la que usa TSL son correctas, pero ambas tienen el defecto de que requieren espera activa. El enfoque que toman no slo desperdicia tiempo de CPU, sino que puede tener efectos inesperados. Considere una computadora con 2 procesos; A que es prioritario, y B, que no lo es. Las reglas de calendarizacin son de tal forma que A se ejecuta siempre que est en estado listo.
En cierto momento, cuando B esta en su regin crtica, A queda listo para ejecutarse. Ahora A inicia una espera activa, pero dado que B nunca se calendariza mientras A se est ejecutando, B nunca tendr oportunidad de salir de su regin crtica, y A seguir dando vueltas en forma indenida. Esta situacin se conoce como problema de inversin de prioridad. Veremos algunas primitivas de comunicacin entre procesos que se bloquean, en lugar de desperdiciar tiempo de CPU, cuando no se les permite entrar en su regin crtica. Una de las ms sencillas es el par sleep y wakeup.
Sleep es una llamada al sistema que hace que el invocador se bloquee, es decir, quede suspendido hasta que otro proceso lo active. La llamada wakeup tiene un parmetro, el proceso por activar. De manera alternativa, tanto wakeup como sleep tienen un parmetro; una direccin de memoria que sirve para relacionar ambas llamadas.
El problema del productor-consumidor

Este problema es un ejemplo donde se usan las primitivas anteriores, tambin se conoce como problema del bfer acotado. Dos procesos comparten un bfer de tamao jo. Uno de ellos el productor coloca informacin all y el otro, el consumidor, la saca. Los problemas surgen cuando el productor quiere colocar un nuevo elemento en el bfer pero ste est lleno.

La solucin es que el productor se desactive y se vuelva a activar cuando el consumidor haya sacado uno o ms elementos. Una situacin similar sucede con el consumidor. Este enfoque parrece sencillo pero da pie a una condicin de competencia como la del spooler de impresin. Para determinar cuantos elementos hay en el bfer necesitaremos una variable, cuenta.

#def ine N 100 / ranuras en el bu f er / int cuenta = 0; / elementos en el bu f er / void productor(void { int elem; while(T RU E ) { / se repite indef inidamente / genera el siguiente elemento / elem = producir elem(); if (cuenta == N ) sleep(); / si el bu f er esta lleno se desactiva / insertar elem(elem); / pone un elemento en el bu f er / cuenta = cuenta + 1; / incrementa num. elem. en bu f er / if (cuenta == 1) wakeup(consumidor); / el bu f er esta vac io? } }

void consumidor(void) { int elem; while(T RU E ) { if (cuenta == 0) sleep(); / si bu f er vac io se desactiva / f er / elem = sacar elem(); / saca un elem del bu cuenta = cuenta 1; / decrementa el num. elem en bu f er / if (cuenta == N 1) wakeup(productor); / el bu f er esta vac io? / consumir elem(elem); / imprime un elemento / } }

La condicin de competencia puede presentarse porque el acceso a cuenta no esta restringido. Podra darse la situacin que el bfer est vaco y el consumidor acaba de leer cuenta para ver si es 0. En ese momento el calendarizador decide dejar de ejecutar el consumidor por el momento y comienza a ejecutar el productor. Este inserta un elemento en el bfer, incrementa cuenta y observa que ahora tiene el valor 1. Eso implica que antes cuenta era 0, as que el consumidor debe estar inactivo, por lo tanto el productor llama a wakeup para activarlo.

Por desgracia, ste todava no esta inactivo lgicamente, por lo que la seal de activar se pierde. La siguiente vez que se ejecute el consumidor, probar el valor de cuenta que ya haba ledo, ver que es 0, y se desactivar. Tarde o temprano el productor llenar el bfer y se desactivar. Ambos estarn inactivos por siempre.
Semforos
Esta era la situacin en 1965, cuando E. W. Dijkstra sugiri el uso de una variable entera para contar el nmero de llamadas wakeup guardadas para uso futuro. En su propuesta introdujo un nuevo tipo de variable llamada semforo. Un semforo puede tener el valor 0, que indica que no se guardaron llamadas wakeup, o algn valor positivo si hay llamadas pendientes. Dijkstra propuso tener dos operaciones: down and up (generalizaciones de sleep and wakeup).
Semforos
La operacin down aplicada a un semforo determina si su valor es mayor que 0. En tal caso decrementa el valor y simplemente contina. Si el valor es 0, el proceso se desactiva sin terminar la operacin down por el momento. Vericar el valor, modicarlo y desactivarlo (en su caso) se efecta como una sola accin atmica (indivisible). Se garantiza que una vez iniciada una operacin de semforo, ningn otro proceso podr tener acceso al semforo antes de que la operacin haya terminado o se haya bloqueado.
Semforos
Esta atomicidad es indispensable para resolver problemas de sincronizacin y evitar condiciones de competencia. La operacin up incrementa el valor del semforo indicado. Si uno o ms procesos estaban inactivos en espera de ese semforo, sin haber podido terminar una operacin down previa, el sistema escoge uno de ellos y le permite terminar. As, despus de un up con un semforo con procesos inactivos, el semforo seguir siendo 0, pero habr un proceso inactivo menos esperndolo. La operacin de incrementar el semforo y activar un proceso tambin es indivisible.
olucin del problema p-c empleando semf

Los semforos resuelven el problema del despertar perdido. Es indispensable que se implemente de manera indivisible. El procedimiento normal es implementar down y up como llamadas al sistema y que el sistema operativo inhabilite en forma breve todas las interrupciones, mientras est probando y actualizando el semforo, as como poniendo el proceso a dormir si es necesario. Dado que todas estas acciones slo requieren unas cuantas instrucciones, la inhabilitacin de las interrupciones no es perjudicial.

Si se estn utilizando mltiples CPUs, cada semforo deber protegerse con una variable de bloqueo, utilizando la instruccin TSL para garantizar que slo un CPU a la vez examine el semforo. Debe entenderse que el uso de TSL para evitar que varias CPUs tengan acceso simultneo al semforo es muy distinto de la espera activa. La operacin de semforo apenas tardar unos cuantos microsegundos, mientras que el productor o el consumidor podran tardar un tiempo arbitrario. La solucin que se presenta utiliza 3 semforos: llenas, vacias y mutex

#def ine N 100 / ranuras en el buf er / typedef int semaf oro; / los semaf oros son int especiales / semaf oro mutex = 1; / controla el acceso a region critica / semaf oro vacias = N ; / cuenta ranuras de buf er vacias / semaf oro llenas = 0; / cuenta ranuras de buf er llenas void productor(void) { int elem; while(T RU E ){ / T RU E es la constante 1 / elem = producir elem(); / genera algo para el buf er / down(&vacias); / decrementa la cuenta de vacias / down(&mutex); / entra en region critica / insertar elem(elem); / pone elem nuevo en buf er / up(&mutex); / sale de la region critica? up(&llenas); / incrementa la cuenta de ranuras ocupadas / } }

void consumidor(void) { int elem; while(T RU E ){ / ciclo inf inito / down(&llenas); / decrementa cuenta de ocupadas / down(&mutex); / entra en region critica / elem = sacar elem(); / saca un elem de buf er up(&mutex); / sale de region critica / up(&vacias); / incrementa cuenta de vacias / consumir elem(elem); / hace algo con el elemento / } }

En el ejemplo anterior los semforos se usan de dos maneras. El uso de mutex es para la exclusin mutua: est diseado para garantizar que slo un proceso estar leyendo o escribiendo en el bfer y las variables asociadas. El otro uso de los semforos es para sincronizacin. Se necesitan para garantizar que ciertas secuencias de sucesos se presenten o no.

Importante

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Importante

Caricato da

Copyright:

Formati disponibili

Sistemas Operativos

Raymundo Marcial Romero Jose

Clase Numero 1 p.1/104

Clase Numero 1 p.2/104

Figure 1: Multiprogramacin de cuatro programas

Cuatro contadores de programa

Clase Numero 1 p.5/104

Cuatro contadores de programa

Clase Numero 1 p.5/104

Clase Numero 1 p.5/104

Clase Numero 1 p.6/104

Clase Numero 1 p.7/104

Clase Numero 1 p.7/104

Clase Numero 1 p.7/104

Clase Numero 1 p.8/104

Clase Numero 1 p.8/104

Clase Numero 1 p.8/104

Clase Numero 1 p.9/104

Clase Numero 1 p.10/104

Clase Numero 1 p.12/104

Clase Numero 1 p.13/104

Clase Numero 1 p.16/104

Clase Numero 1 p.17/104

Clase Numero 1 p.19/104

Clase Numero 1 p.20/104

Clase Numero 1 p.22/104

Clase Numero 1 p.24/104

Clase Numero 1 p.25/104

Clase Numero 1 p.26/104

Clase Numero 1 p.27/104

Clase Numero 1 p.28/104

Clase Numero 1 p.29/104

Clase Numero 1 p.30/104

Clase Numero 1 p.31/104

Clase Numero 1 p.33/104

Clase Numero 1 p.34/104

subproceso Espacio de kernel

Clase Numero 1 p.35/104

Elementos por subproceso Contador de programa Registros Pila Estado

Clase Numero 1 p.38/104

Clase Numero 1 p.40/104

Clase Numero 1 p.42/104

Clase Numero 1 p.43/104

Clase Numero 1 p.46/104

Clase Numero 1 p.47/104

Clase Numero 1 p.49/104

Paralelismo, llamadas no bloqueadoras al sistema, interrupcio

Clase Numero 1 p.50/104

Implementacin de subprocesos en espacio de usuario

Clase Numero 1 p.51/104

Implementacin de subprocesos en espacio de usuario

Sistema de tiempo de ejecucin

Clase Numero 1 p.52/104

Implementacin de subprocesos en espacio de usuario

Clase Numero 1 p.53/104

Implementacin de subprocesos en espacio de usuario

Clase Numero 1 p.54/104

Implementacin de subprocesos en espacio de usuario

Clase Numero 1 p.55/104

Implementacin de subprocesos en espacio de usuario

Clase Numero 1 p.56/104

Implementacin de subprocesos en espacio de kernel

Implementacin de subprocesos en espacio de kernel

Clase Numero 1 p.58/104