Andrew s. Tanenbaum



Descargar 4,35 Mb.
Ver original pdf
Página14/134
Fecha de conversión12.11.2019
Tamaño4,35 Mb.
1   ...   10   11   12   13   14   15   16   17   ...   134

2.1.3  Terminación de procesos

Una vez que se crea un proceso, empieza a ejecutarse y realiza el trabajo al que está destinado. Sin

embargo, nada dura para siempre, ni siquiera los procesos. Tarde o temprano el nuevo proceso ter-

minará, por lo general debido a una de las siguientes condiciones:

1. Salida normal (voluntaria).

2. Salida por error (voluntaria).

3. Error fatal (involuntaria).

4. Eliminado por otro proceso (involuntaria).

La mayoría de los procesos terminan debido a que han concluido su trabajo. Cuando un com-

pilador ha compilado el programa que recibe, ejecuta una llamada al sistema para indicar al siste-

ma operativo que ha terminado. Esta llamada es 

exit


en UNIX y 

ExitProcess

en Windows. Los

programas orientados a pantalla también admiten la terminación voluntaria. Los procesadores de

palabras, navegadores de Internet y programas similares siempre tienen un icono o elemento de me-

nú en el que el usuario puede hacer clic para indicar al proceso que elimine todos los archivos tem-

porales que tenga abiertos y después termine.

La segunda razón de terminación es que el proceso descubra un error. Por ejemplo, si un usua-

rio escribe el comando

cc foo.c


88

PROCESOS E HILOS

CAPÍTULO 2


SECCIÓN 2.1

PROCESOS


89

para compilar el programa foo.c y no existe dicho archivo, el compilador simplemente termina.

Los procesos interactivos orientados a pantalla por lo general no terminan cuando reciben paráme-

tros incorrectos. En vez de ello, aparece un cuadro de diálogo y se le pide al usuario que intente

de nuevo.

La tercera razón de terminación es un error fatal producido por el proceso, a menudo debido a

un error en el programa. Algunos ejemplos incluyen el ejecutar una instrucción ilegal, hacer refe-

rencia a una parte de memoria no existente o la división entre cero. En algunos sistemas (como

UNIX), un proceso puede indicar al sistema operativo que desea manejar ciertos errores por sí mis-

mo, en cuyo caso el proceso recibe una señal (se interrumpe) en vez de terminar.

La cuarta razón por la que un proceso podría terminar es que ejecute una llamada al sistema

que indique al sistema operativo que elimine otros procesos. En UNIX esta llamada es 

kill

. La fun-



ción correspondiente en Win32 es 

TerminateProcess

. En ambos casos, el proceso eliminador debe

tener la autorización necesaria para realizar la eliminación. En algunos sistemas, cuando un proce-

so termina (ya sea en forma voluntaria o forzosa) todos los procesos que creó se eliminan de inme-

diato también. Sin embargo, ni Windows ni UNIX trabajan de esta forma.



2.1.4  Jerarquías de procesos

En algunos sistemas, cuando un proceso crea otro, el proceso padre y el proceso hijo continúan aso-

ciados en ciertas formas. El proceso hijo puede crear por sí mismo más procesos, formando una je-

rarquía de procesos. Observe que, a diferencia de las plantas y los animales que utilizan la

reproducción sexual, un proceso sólo tiene un padre (pero cero, uno, dos o más hijos).

En UNIX, un proceso y todos sus hijos, junto con sus posteriores descendientes, forman un gru-

po de procesos. Cuando un usuario envía una señal del teclado, ésta se envía a todos los miembros

del grupo de procesos actualmente asociado con el teclado (por lo general, todos los procesos acti-

vos que se crearon en la ventana actual). De manera individual, cada proceso puede atrapar la se-

ñal, ignorarla o tomar la acción predeterminada que es ser eliminado por la señal.

Como otro ejemplo dónde la jerarquía de procesos juega su papel, veamos la forma en que

UNIX se inicializa a sí mismo cuando se enciende la computadora. Hay un proceso especial (lla-

mado init) en la imagen de inicio. Cuando empieza a ejecutarse, lee un archivo que le indica cuán-

tas terminales hay. Después utiliza 

fork

para crear un proceso por cada terminal. Estos procesos



esperan a que alguien inicie la sesión. Si un inicio de sesión tiene éxito, el proceso de inicio de se-

sión ejecuta un shell para aceptar comandos. Éstos pueden iniciar más procesos y así sucesivamen-

te. Por ende, todos los procesos en el sistema completo pertenecen a un solo árbol, con init en la

raíz.


En contraste, Windows no tiene un concepto de una jerarquía de procesos. Todos los procesos

son iguales. La única sugerencia de una jerarquía de procesos es que, cuando se crea un proceso, el

padre recibe un indicador especial un token (llamado manejador) que puede utilizar para controlar

al hijo. Sin embargo, tiene la libertad de pasar este indicador a otros procesos, con lo cual invalida

la jerarquía. Los procesos en UNIX no pueden desheredar a sus hijos.


2.1.5  Estados de un proceso

Aunque cada proceso es una entidad independiente, con su propio contador de programa y estado

interno, a menudo los procesos necesitan interactuar con otros. Un proceso puede generar cierta sa-

lida que otro proceso utiliza como entrada. En el comando de shell

cat capitulo1 capitulo2 capitulo3 | grep arbol

el primer proceso, que ejecuta cat, concatena tres archivos y los envía como salida. El segundo pro-

ceso, que ejecuta grep, selecciona todas las líneas que contengan la palabra “arbol”. Dependiendo

de la velocidad relativa de los dos procesos (que dependen tanto de la complejidad relativa de los

programas, como de cuánto tiempo ha tenido cada uno la CPU), puede ocurrir que grep esté listo

para ejecutarse, pero que no haya una entrada esperándolo. Entonces debe bloquear hasta que haya

una entrada disponible.

Cuando un proceso se bloquea, lo hace debido a que por lógica no puede continuar, común-

mente porque está esperando una entrada que todavía no está disponible. También es posible que

un proceso, que esté listo en concepto y pueda ejecutarse, se detenga debido a que el sistema ope-

rativo ha decidido asignar la CPU a otro proceso por cierto tiempo. Estas dos condiciones son com-

pletamente distintas. En el primer caso, la suspensión está inherente en el problema (no se puede

procesar la línea de comandos del usuario sino hasta que éste la haya escrito mediante el teclado).

En el segundo caso, es un tecnicismo del sistema (no hay suficientes CPUs como para otorgar a ca-

da proceso su propio procesador privado). En la figura 2-2 podemos ver un diagrama de estados que

muestra los tres estados en los que se puede encontrar un proceso:

1. En ejecución (en realidad está usando la CPU en ese instante).

2. Listo (ejecutable; se detuvo temporalmente para dejar que se ejecute otro proceso).

3. Bloqueado (no puede ejecutarse sino hasta que ocurra cierto evento externo).

En sentido lógico, los primeros dos estados son similares. En ambos casos el proceso está deseoso

de ejecutarse; sólo en el segundo no hay temporalmente una CPU para él. El tercer estado es dis-

tinto de los primeros dos en cuanto a que el proceso no se puede ejecutar, incluso aunque la CPU

no tenga nada que hacer.

90

PROCESOS E HILOS

CAPÍTULO 2

1

2



3

4

Bloqueado



En ejecución

Listo


1. El proceso se bloquea para recibir entrada

2. El planificador selecciona otro proceso

3. El planificador selecciona este proceso

4. La entrada ya está disponible



Figura 2-2. Un proceso puede encontrarse en estado “en ejecución”, “bloqueado” o

“listo”. Las transiciones entre estos estados son como se muestran.

Hay cuatro transiciones posibles entre estos tres estados, como se indica. La transición 1 ocurre

cuando el sistema operativo descubre que un proceso no puede continuar justo en ese momento. En



SECCIÓN 2.1

PROCESOS


91

algunos sistemas el proceso puede ejecutar una llamada al sistema, como 

pause

, para entrar al es-



tado bloqueado. En otros sistemas, incluyendo a UNIX, cuando un proceso lee datos de una cana-

lización o de un archivo especial (como una terminal) y no hay entrada disponible, el proceso se

bloquea en forma automática.

Las transiciones 2 y 3 son producidas por el planificador de procesos, una parte del sistema

operativo, sin que el proceso sepa siquiera acerca de ellas. La transición 2 ocurre cuando el plani-

ficador decide que el proceso en ejecución se ha ejecutado el tiempo suficiente y es momento de

dejar que otro proceso tenga una parte del tiempo de la CPU. La transición 3 ocurre cuando todos

los demás procesos han tenido su parte del tiempo de la CPU y es momento de que el primer pro-

ceso obtenga la CPU para ejecutarse de nuevo. El tema de la planificación de procesos (decidir qué

proceso debe ejecutarse en qué momento y por cuánto tiempo) es importante; más adelante en este

capítulo lo analizaremos. Se han ideado muchos algoritmos para tratar de balancear las contrastan-

tes demandas de eficiencia para el sistema como un todo y de equidad para los procesos individua-

les; más adelante en este capítulo estudiaremos algunas.

La transición 4 ocurre cuando se produce el evento externo por el que un proceso estaba espe-

rando (como la llegada de ciertos datos de entrada). Si no hay otro proceso en ejecución en ese ins-

tante, se activa la transición 3 y el proceso empieza a ejecutarse. En caso contrario, tal vez tenga

que esperar en el estado listo por unos instantes, hasta que la CPU esté disponible y sea su turno de

utilizarla.

Si utilizamos el modelo de los procesos, es mucho más fácil pensar en lo que está ocurriendo

dentro del sistema. Algunos de los procesos ejecutan programas que llevan a cabo los comandos

que escribe un usuario; otros son parte del sistema y se encargan de tareas como cumplir con las pe-

ticiones de los servicios de archivos o administrar los detalles de ejecutar una unidad de disco o de

cinta magnética. Cuando ocurre una interrupción de disco, el sistema toma una decisión para dejar

de ejecutar el proceso actual y ejecutar el proceso de disco que está bloqueado esperando esta inte-

rrupción. Así, en vez de pensar en las interrupciones, podemos pensar en los procesos de usuario,

procesos de disco, procesos de terminal, etc., que se bloquean cuando están esperando a que algo

ocurra. Cuando se ha leído el disco o se ha escrito el carácter, el proceso que espera se desbloquea

y es elegible para continuar ejecutándose.

Este punto de vista da pie al modelo que se muestra en la figura 2-3. Aquí el nivel más bajo del

sistema operativo es el planificador, con un variedad de procesos encima de él. Todo el manejo de

las interrupciones y los detalles relacionados con iniciar y detener los procesos se ocultan en lo que

aquí se denomina planificador, que en realidad no es mucho código. El resto del sistema operativo

está muy bien estructurado en forma de procesos. Sin embargo, pocos sistemas reales están tan bien

estructurados como éste.



2.1.6  Implementación de los procesos

Para implementar el modelo de procesos, el sistema operativo mantiene una tabla (un arreglo de es-

tructuras) llamada tabla de procesos, con sólo una entrada por cada proceso (algunos autores llaman

a estas entradas bloques de control de procesos). Esta entrada contiene información importante

acerca del estado del proceso, incluyendo su contador de programa, apuntador de pila, asignación de

memoria, estado de sus archivos abiertos, información de contabilidad y planificación, y todo lo de-



más que debe guardarse acerca del proceso cuando éste cambia del estado en ejecución listo blo-

queado, de manera que se pueda reiniciar posteriormente como si nunca se hubiera detenido.

La figura 2-4 muestra algunos de los campos clave en un sistema típico. Los campos en la pri-

mera columna se relacionan con la administración de procesos; los otros dos se relacionan con la

administración de memoria y archivos, respectivamente. Hay que recalcar que los campos conteni-

dos en la tabla de procesos varían de un sistema a otro, pero esta figura nos da una idea general de

los tipos de información necesaria.



Figura 2-4. Algunos de los campos de una entrada típica en la tabla de procesos.

Ahora que hemos analizado la tabla de procesos, es posible explicar un poco más acerca de có-

mo la ilusión de varios procesos secuenciales se mantiene en una (o en varias) CPU. Con cada cla-

se de E/S hay una ubicación asociada (por lo general, en una ubicación cerca de la parte 

final de la memoria), a la cual se le llama vector de interrupción. Esta ubicación contiene la di-

rección del procedimiento del servicio de interrupciones. Suponga que el proceso de usuario 3 está 

en ejecución cuando ocurre una interrupción de disco. El contador de programa, la palabra de estado

92

PROCESOS E HILOS

CAPÍTULO 2

0

1



n – 2 n – 1

Planificador

Procesos

Figura 2-3. La capa más baja de un sistema operativo estructurado por procesos se en-

carga de las interrupciones y la planificación. Encima de esa capa están los procesos se-

cuenciales.

Administración de procesos 

Administración de memoria 

Administración de archivos  

Registros

Apuntador a la información 

Directorio raíz

Contador del programa

del segmento de texto

Directorio de trabajo

Palabra de estado del programa

Apuntador a la información 

Descripciones de archivos

Apuntador de la pila

del segmento de datos

ID de usuario

Estado del proceso

Apuntador a la información

ID de grupo  

Prioridad

del segmento de pila 

Parámetros de planificación

ID del proceso

Proceso padre

Grupo de procesos

Señales

Tiempo de inicio del proceso



Tiempo utilizado de la CPU

Tiempo de la CPU utilizado por 

el hijo

Hora de la siguiente alarma 



SECCIÓN 2.1

PROCESOS


93

del programa y algunas veces uno o más registros del proceso del usuario 3 se meten en la pila (ac-

tual) mediante el hardware de interrupción. Después, la computadora salta a la dirección especifi-

cada en el vector de interrupción. Esto es todo lo que hace el hardware. De aquí en adelante,

depende del software y en especial del procedimiento del servicio de interrupciones.

Todas las interrupciones empiezan por guardar los registros, a menudo en la entrada de la tabla

de procesos para el proceso actual. Después, se quita la información que la interrupción metió en la

pila y el apuntador de pila se establece para que apunte a una pila temporal utilizada por el manejador

de procesos. Las acciones como guardar los registros y establecer el apuntador de pila no se pueden

expresar ni siquiera en lenguajes de alto nivel tales como C, por lo que se realizan mediante una pe-

queña rutina en lenguaje ensamblador, que por lo general es la misma para todas las interrupciones,

ya que el trabajo de guardar los registros es idéntico, sin importar cuál sea la causa de la interrupción.

Cuando termina esta rutina, llama a un procedimiento en C para realizar el resto del trabajo 

para este tipo de interrupción específico (suponemos que el sistema operativo está escrito en C, la

elección usual para todos los sistemas operativos reales). Cuando ha terminado su trabajo y tal vez

ocasionando que algún otro proceso esté entonces listo, el planificador es llamado para ver qué pro-

ceso se debe ejecutar a continuación. Después de eso, el control se pasa de vuelta al código en len-

guaje ensamblador para cargar los registros y el mapa de memoria para el proceso que entonces es

el actual y se empieza a ejecutar. En la figura 2-5 se sintetizan el manejo de interrupciones y la pla-

nificación de proceso. Vale la pena recalcar que los detalles varían dependiendo del sistema.

1. El hardware mete el contador del programa a la pila, etc.

2. El hardware carga el nuevo contador de programa del vector de interrupciones.

3. Procedimiento en lenguaje ensamblador guarda los registros.

4. Procedimiento en lenguaje ensamblador establece la nueva pila.

5. El servicio de interrupciones de C se ejecuta (por lo general lee y guarda la entrada en el búfer).

6. El planificador decide qué proceso se va a ejecutar a continuación.

7. Procedimiento en C regresa al código de ensamblador.

8. Procedimiento en lenguaje ensamblador inicia el nuevo proceso actual.



Figura 2-5. Esqueleto de lo que hace el nivel más bajo del sistema operativo cuando

ocurre una interrupción.

Cuando el proceso termina, el sistema operativo muestra un carácter indicador y espera un nue-

vo comando. Cuando recibe el comando, carga un nuevo programa en memoria, sobrescribiendo el

anterior.

2.1.7 Modelación de la multiprogramación

Cuando se utiliza la multiprogramación, el uso de la CPU se puede mejorar. Dicho en forma cruda:

si el proceso promedio realiza cálculos sólo 20 por ciento del tiempo que está en la memoria, con

cinco procesos en memoria a la vez la CPU deberá estar ocupada todo el tiempo. Sin embargo, es-

te modelo es demasiado optimista, ya que supone que los cinco procesos nunca estarán esperando

la E/S al mismo tiempo.



Un mejor modelo es analizar el uso de la CPU desde un punto de vista probabilístico. Supon-

ga que un proceso gasta una fracción de su tiempo esperando a que se complete una operación de

E/S. Con procesos en memoria a la vez, la probabilidad de que todos los procesos estén espe-

rando la E/S (en cuyo caso, la CPU estará inactiva) es p



n

. Entonces, el uso de la CPU se obtiene

mediante la fórmula

Uso de la CPU 

 1  p

n

La figura 2-6 muestra el uso de la CPU como una función de n, a lo cual se le conoce como el gra-



do de multiprogramación.

94

PROCESOS E HILOS

CAPÍTULO 2

50% en espera de E/S

80% en espera de E/S

20% en espera de E/S

100

80

60



40

20

1



2

3

4



5

6

7



8

9

10



0

Grado de multiprogramación

Uso de la CPU (en porcentaje)

Figura 2-6. Uso de la CPU como una función del número de procesos en memoria.

La figura deja claro que, si los procesos gastan 80 por ciento de su tiempo esperando las ope-

raciones de E/S, por lo menos debe haber 10 procesos en memoria a la vez para que el desperdicio

de la CPU esté por debajo de 10%. Cuando nos damos cuenta de que un proceso interactivo, que

espera a que un usuario escriba algo en una terminal, está en un estado de espera de E/S, debe es-

tar claro que los tiempos de espera de E/S de 80 por ciento o más no son poco comunes. Pero in-

cluso en los servidores, los procesos que realizan muchas operaciones de E/S en disco tendrán a

menudo este porcentaje o más.

Para obtener una precisión completa, debemos recalcar que el modelo probabilístico que aca-

bamos de describir es sólo una aproximación. Supone en forma implícita que los procesos son in-

dependientes, lo cual significa que es bastante aceptable para un sistema con cinco procesos en

memoria, tener tres en ejecución y dos en espera. Pero con una sola CPU no podemos tener tres pro-

cesos en ejecución a la vez, por lo que un proceso que cambie al estado listo mientras la CPU esté

ocupada tendrá que esperar. Por ende, los procesos no son independientes. Podemos construir un

modelo más preciso mediante la teoría de colas, pero el punto que queremos establecer (la multi-

programación permite que los procesos utilicen la CPU cuando de lo contrario estaría inactiva) es,

desde luego, todavía válido, aun si las curvas verdaderas de la figura 2-6 son ligeramente distintas

de las que se muestran en la figura.



SECCIÓN 2.2

HILOS


95

Aun cuando el modelo de la figura 2-6 es simple, de todas formas se puede utilizar para reali-

zar predicciones específicas (aunque aproximadas) acerca del rendimiento de la CPU. Por ejemplo,

suponga que una computadora tiene 512 MB de memoria, de la cual el sistema operativo ocupa 128

MB y cada programa de usuario ocupa otros 128 MB. Estos tamaños permiten que haya tres pro-

gramas de usuario en memoria a la vez. Con un promedio de 80 por ciento de tiempo de espera de

E/S, tenemos una utilización de la CPU (ignorando la sobrecarga del sistema operativo) de 1 – 0.8

3

o de aproximadamente 49 por ciento. Si agregamos 512 MB más de memoria, el sistema puede pa-



sar de la multiprogramación de tres vías a una multiprogramación de siete vías, con lo cual el uso

de la CPU se eleva hasta 79 por ciento. En otras palabras, los 512 MB adicionales elevarán el ren-

dimiento por 30 por ciento.

Si agregamos otros 512 MB, el uso de la CPU sólo se incrementaría de 79 a 91 por ciento, 

con lo cual se elevaría el rendimiento sólo en 12% adicional. Utilizando este modelo, el propieta-

rio de la computadora podría decidir que la primera adición es una buena inversión, pero la segun-

da no.

2.2 HILOS

En los sistemas operativos tradicionales, cada proceso tiene un espacio de direcciones y un solo hi-

lo de control. De hecho, ésa es casi la definición de un proceso. Sin embargo, con frecuencia hay

situaciones en las que es conveniente tener varios hilos de control en el mismo espacio de direccio-

nes que se ejecuta en cuasi-paralelo, como si fueran procesos (casi) separados (excepto por el espa-

cio de direcciones compartido). En las siguientes secciones hablaremos sobre estas situaciones y sus

implicaciones.

2.2.1 Uso de hilos

¿Por qué alguien querría tener un tipo de proceso dentro de otro proceso? Resulta ser que hay va-

rias razones de tener estos miniprocesos, conocidos como hilos. Ahora analizaremos algunos de

ellos. La principal razón de tener hilos es que en muchas aplicaciones se desarrollan varias activi-

dades a la vez. Algunas de ésas se pueden bloquear de vez en cuando. Al descomponer una aplica-

ción en varios hilos secuenciales que se ejecutan en cuasi-paralelo, el modelo de programación se

simplifica.

Ya hemos visto este argumento antes: es precisamente la justificación de tener procesos. En vez

de pensar en interrupciones, temporizadores y conmutaciones de contexto, podemos pensar en pro-

cesos paralelos. Sólo que ahora con los hilos agregamos un nuevo elemento: la habilidad de las en-

tidades en paralelo de compartir un espacio de direcciones y todos sus datos entre ellas. Esta

habilidad es esencial para ciertas aplicaciones, razón por la cual no funcionará el tener varios pro-

cesos (con sus espacios de direcciones separados).

Un segundo argumento para tener hilos es que, como son más ligeros que los procesos, son mas

fáciles de crear (es decir, rápidos) y destruir. En muchos sistemas, la creación de un hilo es de 10 a

100 veces más rápida que la de un proceso. Cuando el número de hilos necesarios cambia de ma-

nera dinámica y rápida, es útil tener esta propiedad.


Una tercera razón de tener hilos es también un argumento relacionado con el rendimiento. Los

hilos no producen un aumento en el rendimiento cuando todos ellos están ligados a la CPU, pero

cuando hay una cantidad considerable de cálculos y operaciones de E/S, al tener hilos estas activi-

dades se pueden traslapar, con lo cual se agiliza la velocidad de la aplicación.

Por último, los hilos son útiles en los sistemas con varias CPUs, en donde es posible el verda-

dero paralelismo. En el capítulo 8 volveremos a ver esta cuestión.

Es más fácil ver por qué los hilos son útiles si utilizamos ejemplos concretos. Como primer

ejemplo considere un procesador de palabras. Por lo general, los procesadores de palabras muestran

el documento que se va crear en la pantalla exactamente como aparecerá en la página impresa. En

especial, todos los saltos de línea y de página están en sus posiciones correctas y finales, de mane-

ra que el usuario pueda inspeccionarlas y cambiar el documento si es necesario (por ejemplo, para

eliminar viudas huérfanas, líneas superiores e inferiores incompletas que se consideran estética-

mente desagradables). 

Suponga que el usuario está escribiendo un libro. Desde el punto de vista del autor, es más fá-

cil mantener todo el libro en un solo archivo para facilitar la búsqueda de temas, realizar sustitucio-

nes globales, etc. También, cada capítulo podría estar en un archivo separado; sin embargo, tener

cada sección y subsección como un archivo separado puede ser una verdadera molestia si hay que

realizar cambios globales en todo el libro, ya que entonces tendrían que editarse cientos de archi-

vos en forma individual. Por ejemplo, si se aprueba el estándar xxxx propuesto justo antes de que

el libro vaya a la imprenta, todas las ocurrencias del “Estándar xxxx en borrador” tendrían que cam-

biarse por “Estándar xxxx” a última hora. Si todo el libro está en un archivo, por lo general un so-

lo comando puede realizar todas las sustituciones. Por el contrario, si el libro está esparcido en más

de 300 archivos, cada uno se debe editar por separado.

Ahora considere lo que ocurre cuando el usuario repentinamente elimina un enunciado de la

página 1 de un documento de 800 páginas. Después de revisar que la página modificada esté co-

rrecta, el usuario desea realizar otro cambio en la página 600 y escribe un comando que indica al

procesador de palabras que vaya a esa página (posiblemente mediante la búsqueda de una frase que

sólo esté en esa página). Entonces, el procesador de palabras tiene que volver a dar formato a todo

el libro hasta la página 600 en ese momento, debido a que no sabe cuál será la primera línea de la

página 600 sino hasta que haya procesado las demás páginas. Puede haber un retraso considerable

antes de que pueda mostrar la página 600 y el usuario estaría descontento.

Aquí pueden ayudar los hilos. Suponga que el procesador de palabras se escribe como un pro-

grama con dos hilos. Un hilo interactúa con el usuario y el otro se encarga de volver a dar formato

en segundo plano. Tan pronto como se elimina el enunciado de la página 1, el hilo interactivo indi-

ca al hilo encargado de volver a dar formato que aplique de nuevo formato a todo el libro. Mientras

tanto, el hilo interactivo sigue esperando las acciones del teclado y del ratón y responde a coman-

dos simples como desplazarse por la página 1, mientras el otro hilo está realizando cálculos inten-

sivos en segundo plano. Con algo de suerte, el proceso de volver a dar formato se completará antes

de que el usuario pida ver la página 600, para que pueda mostrarse al instante.

Ya que estamos en ello, ¿por qué no agregar un tercer hilo? Muchos procesadores de pala-

bras tienen la característica de guardar de manera automática todo el archivo en el disco cada

cierto número de minutos, para proteger al usuario contra la pérdida de todo un día de trabajo en

caso de un fallo en el programa, el sistema o la energía. El tercer hilo se puede encargar de los



Compartir con tus amigos:
1   ...   10   11   12   13   14   15   16   17   ...   134


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal