Summary
Summary Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 2
- Course
- Institution
- Book
Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 2 en Español
[Show more]
Connected book
Book Title:
Author(s):
- Edition:
- ISBN:
- Edition:
More summaries for
-
Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 1
-
Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 3
-
Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 5
Seller
Follow
agusmitrobeda
Content preview
2PROCESOS E HILOS
Estamos a punto de emprender el estudio detallado de cómo los sistemas operativos son diseñados
y construidos. El concepto más importante en cualquier sistema operativo es el de proceso, una abs-
tracción de un programa en ejecución; todo lo demás depende de este concepto, por lo cual es im-
portante que el diseñador del sistema operativo (y el estudiante) tenga una comprensión profunda
acerca de lo que es un proceso lo más pronto posible.
Los procesos son una de las abstracciones más antiguas e importantes que proporcionan los sis-
temas operativos: proporcionan la capacidad de operar (pseudo) concurrentemente, incluso cuando
hay sólo una CPU disponible. Convierten una CPU en varias CPU virtuales. Sin la abstracción de
los procesos, la computación moderna no podría existir. En este capítulo examinaremos con gran
detalle los procesos y sus primeros primos, los hilos (threads).
2.1 PROCESOS
Todas las computadoras modernas ofrecen varias cosas al mismo tiempo; quienes están acostum-
brados a trabajar con ellas tal vez no estén completamente conscientes de este hecho, por lo que uti-
lizaremos algunos ejemplos para aclarar este punto. Consideremos primero un servidor Web, a
donde convergen las peticiones de páginas Web provenientes de todos lados. Cuando llega una pe-
tición, el servidor verifica si la página que se necesita está en la caché. De ser así, devuelve la pá-
gina; en caso contrario, inicia una petición al disco para obtenerla y, desde la perspectiva de la CPU,
estas peticiones tardan eternidades. Mientras se espera el cumplimiento de una petición, muchas
83
,84 PROCESOS E HILOS CAPÍTULO 2
más pueden llegar. Si hay varios discos presentes, algunas o todas las demás peticiones podrían di-
rigirse a otros discos mucho antes de que se cumpla la primera petición. Es evidente que se necesita
cierta forma de modelar y controlar esta concurrencia. Los procesos (y en especial los hilos) pueden
ayudar en este caso.
Ahora consideremos una PC de usuario. Cuando se arranca el sistema se inician muchos proce-
sos en forma secreta, lo que a menudo el usuario desconoce. Por ejemplo, se podría iniciar un pro-
ceso para esperar el correo electrónico entrante; otro que permite al antivirus comprobar perió-
dicamente la disponibilidad de nuevas definiciones de virus; algunos procesos de usuario explícitos
para, por ejemplo, imprimir archivos y quemar un CD-ROM, y todo esto mientras el usuario nave-
ga por la Web. Toda esta actividad se tiene que administrar, y en este caso un sistema de multipro-
gramación con soporte para múltiples procesos es muy útil.
En cualquier sistema de multiprogramación, la CPU conmuta de un proceso a otro con rapidez,
ejecutando cada uno durante décimas o centésimas de milisegundos: hablando en sentido estricto,
en cualquier instante la CPU está ejecutando sólo un proceso, y en el transcurso de 1 segundo po-
dría trabajar en varios de ellos, dando la apariencia de un paralelismo (o pseudoparalelismo, para
distinguirlo del verdadero paralelismo de hardware de los sistemas multiprocesadores con dos o
más CPUs que comparten la misma memoria física). Es difícil para las personas llevar la cuenta de
varias actividades en paralelo; por lo tanto, los diseñadores de sistemas operativos han evoluciona-
do con el paso de los años a un modelo conceptual (procesos secuenciales) que facilita el trabajo
con el paralelismo. Este modelo, sus usos y algunas de sus consecuencias conforman el tema de es-
te capítulo.
2.1.1 El modelo del proceso
En este modelo, todo el software ejecutable en la computadora, que algunas veces incluye al sis-
tema operativo, se organiza en varios procesos secuenciales (procesos, para abreviar). Un proce-
so no es más que una instancia de un programa en ejecución, incluyendo los valores actuales del
contador de programa, los registros y las variables. En concepto, cada proceso tiene su propia
CPU virtual; en la realidad, la CPU real conmuta de un proceso a otro, pero para entender el sis-
tema es mucho más fácil pensar en una colección de procesos que se ejecutan en (pseudo) para-
lelo, en vez de tratar de llevar la cuenta de cómo la CPU conmuta de programa en programa. Esta
conmutación rápida de un proceso a otro se conoce como multiprogramación, como vimos en el
capítulo 1.
La figura 2-1(a) muestra una computadora multiprogramando cuatro programas en memoria;
la figura 2-1(b) lista cuatro procesos, cada uno con su propio flujo de control (es decir, su propio
contador de programa lógico) y cada uno ejecutándose en forma independiente. Desde luego que
sólo hay un contador de programa físico, por lo que cuando se ejecuta cada proceso, se carga su
contador de programa lógico en el contador de programa real. Cuando termina (por el tiempo que
tenga asignado), el contador de programa físico se guarda en el contador de programa lógico alma-
cenado, del proceso en memoria. En la figura 2-1(c) podemos ver que durante un intervalo suficien-
temente largo todos los procesos han progresado, pero en cualquier momento dado sólo hay un
proceso en ejecución.
,SECCIÓN 2.1 PROCESOS 85
Un contador de programa Cuatro contadores
de programa
Conmutación
A
de proceso
D
Proceso
B
C
C A B C D B
A
D Tiempo
(a) (b) (c)
Figura 2-1. (a) Multiprogramación de cuatro programas. (b) Modelo conceptual de
cuatro procesos secuenciales independientes. (c) Sólo hay un programa activo a la vez.
En este capítulo vamos a suponer que sólo hay una CPU, aunque esa condición cada vez suce-
de menos en la realidad debido a que los nuevos chips son multinúcleo, con dos, cuatro o más
CPUs. En el capítulo 8 analizaremos los chips multinúcleo y los multiprocesadores en general;
mientras tanto es más simple considerar sólo una CPU a la vez. Así, cuando decimos que una CPU
puede ejecutar sólo un proceso a la vez, si hay dos núcleos (o CPUs) cada uno de ellos puede eje-
cutar sólo un proceso a la vez.
Dado que la CPU conmuta rápidamente entre un proceso y otro, la velocidad a la que un pro-
ceso ejecuta sus cálculos no es uniforme y tal vez ni siquiera sea reproducible si se ejecutan los mis-
mos procesos de nuevo. Por ende, al programar los procesos debe asumirse esta variación de
velocidad. Por ejemplo, considere un proceso de E/S que inicia una unidad de cinta magnética pa-
ra restaurar los archivos respaldados, ejecuta un ciclo de inactividad 10,000 veces para permitir que
obtenga la velocidad adecuada y después emite un comando para leer el primer registro. Si la CPU
decide conmutar a otro proceso durante el ciclo de inactividad, el proceso de la cinta tal vez no se
ejecute de nuevo sino hasta que el primer registro se encuentre más allá de la cabeza de lectura.
Cuando un proceso tiene requerimientos críticos de tiempo real como éste, es decir, cuando deben
ocurrir eventos específicos dentro de un número especificado de milisegundos, es necesario tomar
medidas especiales para asegurar que ocurran. Sin embargo, por lo general la mayoría de los pro-
cesos no se ven afectados por la multiprogramación subyacente de la CPU o las velocidades relati-
vas de distintos procesos.
La diferencia entre un proceso y un programa es sutil pero crucial. Aquí podría ayudarnos una
analogía: un científico computacional con mente culinaria hornea un pastel de cumpleaños para su
hija; tiene la receta para un pastel de cumpleaños y una cocina bien equipada con todos los ingre-
dientes: harina, huevos, azúcar, extracto de vainilla, etcétera. En esta analogía, la receta es el pro-
grama (es decir, un algoritmo expresado en cierta notación adecuada), el científico computacional
es el procesador (CPU) y los ingredientes del pastel son los datos de entrada. El proceso es la acti-
vidad que consiste en que nuestro cocinero vaya leyendo la receta, obteniendo los ingredientes y
horneando el pastel.
, 86 PROCESOS E HILOS CAPÍTULO 2
Ahora imagine que el hijo del científico entra corriendo y gritando que una abeja acaba de pi-
carlo. El científico computacional registra el punto de la receta en el que estaba (el estado del proce-
so en curso se guarda), saca un libro de primeros auxilios y empieza a seguir las instrucciones que
contiene. Aquí el procesador conmuta de un proceso (hornear el pastel) a uno de mayor prioridad (ad-
ministrar cuidados médicos), cada uno de los cuales tiene un programa distinto (la receta y el libro
de primeros auxilios). Cuando ya se ha ocupado de la picadura de abeja, el científico computacional
regresa a su pastel y continúa en el punto en el que se había quedado.
La idea clave es que un proceso es una actividad de cierto tipo: tiene un programa, una entra-
da, una salida y un estado. Varios procesos pueden compartir un solo procesador mediante el uso de
un algoritmo de planificación para determinar cuándo se debe detener el trabajo en un proceso pa-
ra dar servicio a otro.
Vale la pena recalcar que si un programa se está ejecutando por duplicado cuenta como dos pro-
cesos. Por ejemplo, a menudo es posible iniciar un procesador de palabras dos veces o imprimir dos
archivos al mismo tiempo si hay dos impresoras disponibles. El hecho de que dos procesos en eje-
cución tengan el mismo programa no importa; son procesos distintos. El sistema operativo puede
compartir el código entre ellos de manera que sólo haya una copia en la memoria, pero ése es un
detalle técnico que no cambia la situación conceptual de dos procesos en ejecución.
2.1.2 Creación de un proceso
Los sistemas operativos necesitan cierta manera de crear procesos. En sistemas muy simples o sis-
temas diseñados para ejecutar sólo una aplicación (por ejemplo, el controlador en un horno de mi-
croondas), es posible tener presentes todos los procesos que se vayan a requerir cuando el sistema
inicie. No obstante, en los sistemas de propósito general se necesita cierta forma de crear y termi-
nar procesos según sea necesario durante la operación. Ahora analizaremos varias de estas cues-
tiones.
Hay cuatro eventos principales que provocan la creación de procesos:
1. El arranque del sistema.
2. La ejecución, desde un proceso, de una llamada al sistema para creación de procesos.
3. Una petición de usuario para crear un proceso.
4. El inicio de un trabajo por lotes.
Generalmente, cuando se arranca un sistema operativo se crean varios procesos. Algunos de ellos
son procesos en primer plano; es decir, procesos que interactúan con los usuarios (humanos) y rea-
lizan trabajo para ellos. Otros son procesos en segundo plano, que no están asociados con usuarios
específicos sino con una función específica. Por ejemplo, se puede diseñar un proceso en segundo
plano para aceptar el correo electrónico entrante, que permanece inactivo la mayor parte del día pe-
ro que se activa cuando llega un mensaje. Se puede diseñar otro proceso en segundo plano para
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller agusmitrobeda. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $5.49. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
79373 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy study notes for 14 years now
Recently viewed by you
