Disponible la nueva versión "donationware" 7.3 de OrganiZATOR
Descubre un nuevo concepto en el manejo de la información.
La mejor ayuda para sobrevivir en la moderna jungla de datos la tienes aquí.

Curso C++

[Home]  [Inicio]  [Índice]


Multiprograma & Multitarea

§1  Comentario

Los conceptos someramente expuestos en la página anterior pueden ser desde luego objeto de controversia. Además, desgraciadamente la nomenclatura informática no es demasiado consistente al respecto, y la cuestión se complica un poco más si consideramos la traducción del inglés aplicada en cada caso [1]. Así pues, los conceptos, programa, proceso ("Process") y hebra ("Thread"), y sus respectivos "plurales" (multi-programa; multrproceso y multihebra) distan mucho de estar tan claros como sería deseable.

A veces, las diferencias entre los conceptos son sutiles, y dependen de la perspectiva  o punto de vista adoptado para considerar la cuestión. Como botón de muestra incluimos un par de párrafos (respetando el original inglés).  El primero, del libro "Programming Windows"; un clásico de Charles Petzold ( 7). Paj. 1197 [6]

Multitasking is the ability of an operating system to run multiple programs concurrently. Basically, the operating system uses a hardware clock to allocate "time slices" for each currently running process. If the time slices are small enough—and the machine is not overloaded with too many programs trying to do something—it appears to a user as if all the programs are running simultaneously. 

Multitasking is nothing new. On large mainframe computers, multitasking is a given. These mainframes often have hundreds of terminals attached to them, and each terminal user should get the impression that he or she has exclusive access to the whole machine. In addition, mainframe operating systems often allow users to "submit jobs to the background," where they are then carried out by the machine while the user can work on something else. 

Multitasking on personal computers has taken much longer to become a reality. But we now often seem to take PC multitasking for granted. As I'll discuss shortly, to some extent the earlier 16-bit versions of Microsoft Windows supported multitasking but in a somewhat limited capability. The 32-bit versions of Windows all support both true multitasking and—as an extra bonus—multithreading. 

Multithreading is the ability for a program to multitask within itself. The program can split itself into separate "threads" of execution that also seem to run concurrently. This concept might at first seem barely useful, but it turns out that programs can use multithreading to perform lengthy jobs in the background without requiring the user to take an extended break away from their machines. Of course, sometimes this may not be desired: an excuse to take a journey to the watercooler or refrigerator is often welcome! But the user should always be able to do something on the machine, even when it's busy doing something else.

El segundo, del libro "Secure Programming for Linux and Unix HOWTO" de David A. Wheeler    www.dwheeler.com:

In Unix-like systems, user-level activities are implemented by running processes. Most Unix systems support a "thread'' as a separate concept;  threads share memory inside a process, and the system scheduler actually schedules threads. Linux does this differently (and in my opinion uses a better approach):  there is no essential difference between a thread and a process. Instead, in Linux, when a process creates another process it can choose what resources are shared (e.g., memory can be shared). The Linux kernel then performs optimizations to get thread-level speeds; see clone(2) for more information. It's worth noting that the Linux kernel developers tend to use the word "task'', not "thread'' or "process'', but the external documentation tends to use the word process (so I'll use the term "process'' here).

When programming a multi-threaded application, it's usually better to use one of the standard thread libraries that hide these differences. Not only does this make threading more portable, but some libraries provide an additional level of indirection, by implementing more than one application-level thread as a single operating system thread; this can provide some improved performance on some systems for some applications.



§2  En rigor, todo el Software que se ejecuta en el ordenador puede ser considerado un "programa", más o menos complicado, cuya finalidad es una u otra. De forma general, entendemos un "Programa" como un conjunto de instrucciones organizadas de forma que dirigen al hardware para realizar una tarea determinada. En este sentido, tanto un "Driver" como el propio Sistema Operativo, y los programas de aplicación son "programas" [2]; se trata por tanto de un concepto muy general.

A los efectos que nos ocupan asimilaremos el concepto de programa con un fichero (ejecutable) que cuando es llamado a ejecución origina un proceso (en los sistemas Unix el concepto de proceso está ligado a la actividad de un usuario).


§3  Un procesador actual solo puede ejecutar un programa cada vez. Esto, con independencia de que su arquitectura interna permita un cierto grado de "paralelismo" en las operaciones. Por ejemplo, que pueda estar realizando una operación con los registros y al mismo tiempo estar accediendo a una posición de memoria para traer el próximo dato.

Así pues, en sentido estricto un ordenador con un solo procesador será siempre monoprograma. Cuando decimos que un SO como Windows es multiprograma, aunque se  esté ejecutando en una máquina con un solo procesador,  en realidad se habla en sentido figurado. No se ejecutan diversos programas de forma "simultanea" sino alternada; todo lo más diríamos: de forma "concurrente".

En estos casos, lo que ocurre en realidad es que el procesador está asignando tiempo de ejecución a diversos programas según un determinado criterio (que puede ser muy sofisticado). La percepción es que varios programas se ejecutan de forma simultanea, aunque la verdadera naturaleza de la operación es lo que se denomina tiempo compartido ("time sharing") [3].

Para que exista una verdadera multiprogramación [4] se necesita un hardware con dos o más procesadores, y un SO que sepa sacar partido de esta circunstancia. En estas condiciones si podemos afirmar con propiedad que se ejecutan simultáneamente varios programas.

Nota: en lo que respecta al hardware, esta última es la situación actual en aquellas máquinas con dos procesadores. Por ejemplo las placas-base Intel dual Xeon, o bien con un solo procesador "dual". Por ejemplo, los Intel Core™ Duo.


§4  El concepto multihebra ("multithreading") es de tipo lógico. Significa que un programa puede tener varias vías de ejecución que "pueden" ser independientes. Por ejemplo:  Un procesador de texto puede tener una hebra que es utilizada por el usuario para escribir y otra, que a periodos de tiempo determinados, salva a disco el contenido de la memoria, obteniendo así una copia de seguridad. Según hemos visto (Wheeler ), desde el punto de vista físico, lo que caracteriza a las diversas hebras de un proceso es que comparten ciertos recursos dentro del mismo;  por ejemplo la memoria, los ficheros abiertos y las variables estáticas, mientras que mantienen independencia en los recursos que les permiten una ejecución independiente, por ejemplo su propia pila ("Stack" 2.2.6) y el estado de los registros del procesador, que es salvado y restituido cada vez que la hebra es desactivada o activada.

Lo importante aquí es que desde un punto de vista lógico, las hebras corren de forma simultanea e independiente (lo que no impide que pueda existir cierta coordinación entre ellas, de forma que, por ejemplo, una puede esperar hasta que otra ha terminado cierto trabajo). Que esta "simultaneidad" sea o no real no es lo más importante. En cualquier caso, la percepción del usuario es que todas corren simultanea e independientemente.

El resultado de enfocar una aplicación como multiprograma o multihebra puede ser muy parecido, aunque cada solución tiene sus propias características. A título de ejemplo incluimos las explicaciones correspondientes al servidor Apache que existe en dos versiones:  la versión 1.3 lanza un proceso por cada servicio que debe atender;  la versión 2.0 utiliza un solo proceso con una hebra por cada servicio. Tomado de: Apache Overview HOWTO de Daniel Lopez Ridruejo    www.tldp.org

Apache 1.3 on Unix is a process-based Web server. The Apache program forks several children at startup. Forking means that a parent process makes identical copies of itself, called children. Each one of the children can serve a request independent of the others. This approach has the advantage of improved stability: If one of the children misbehaves (runs out of control or has memory leaks) it can be terminated without affecting the others. The stability comes with a performance penalty. In most Unix operating systems, creating processes and context switching (assigning processor time to each process) are expensive operations. Since processes are isolated from each other, they cannot easily share code and data, consuming system resources.

Apache 2.0 abstracts the request processing architecture in special server modules, called Multi Processing modules (MPMs). This means that Apache can be configured to be a pure process-based server, a purely threaded server or a mixture of those models. Threads are contained inside processes and run simultaneously. Unlike processes, threads can share data and code. Threads are thus more "lighweight" than processes, and in most cases threaded servers scale better than process based servers. The disadvantage is that the server is less reliable, since if a thread misbehaves it can corrupt data or code belonging to other threads.


§5  En realidad, en un ordenador de un solo procesador con un sistema operativo tipo Windows, solo corre un programa, el kernel del sistema; este programa reside permanentemente en memoria y es multihebra, puede tener varias vías de ejecución [5]. Unas son internas del propio sistema e imprescindibles; otras comienzan y terminan a voluntad del usuario, son los programas de aplicación. Como decíamos, cada una de estas vías de ejecución recibe tiempo de proceso según determinados criterios. Desde la óptica del usuario, algunas de ellas son "programas". A su vez, desde la óptica del programador y del usuario, una de estas aplicaciones o "hebras" del sistema, puede ser multihebra.

  Inicio.


[1]  No olvidemos que el origen de estas denominaciones es casi siempre inglés; la mayoría de los desarrollos de la informática de los últimos 40 años tienen su origen en USA e Inglaterra. En cualquier caso, y en lo referente a este epígrafe, no pretendemos entrar en discusiones semánticas, sino todo lo contrario, fijar y clarificar algunas ideas al respecto.

[2]  En el caso del SO (Windows o Linux por ejemplo), en realidad no es un solo programa, sino multitud de ellos que interactúan y se llaman unos a otros.

[3]  Los primeros intentos de algo parecido a la multiprogramación actual fueron precisamente sistemas de tiempo compartido bastante rudimentarios, en los que la asignación de tiempos a cada una de las "tareas" se efectuaba a intervalos de tiempo fijos. El primer sistema serio, el CTSS (Compatible Time Sharing System), fue desarrollado en el MIT sobre la base de un equipo IBM 7094 convenientemente adaptado.

[4]  Los autores ingleses utilizan "multitasking" y "multiprogramming" casi como sinónimos. Por ejemplo, refiriéndose al SO Windows, Petzold nos dice: "Windows 98 and Windows NT are 32-bit preemptive multitasking and multithreading graphical operating systems" (Petzold PW 5E  paj. 6). Creemos que sería más afortunado decir "preemptive multiprogramming and multithreading". Nosotros preferimos utilizar los términos multiprograma y multitarea, empleando este último término como sinónimo de multihebra.

[5]  El Kernel o nucleo del sistema se ocupa básicamente de tres tareas primordiales: Gestión de memoria; gestión de E/S a disco y control de las tareas en ejecución.Respecto a este último punto, dejemos que sean las autorizadas palabras de Thomas West, el que fuera director de investigación y desarrollo de Data General, el que nos lo explique:

Very few people are delivering symmetric multiprocessing at this time (N. del A: en 1990). It's allowing us to get a wide range of functionality out of a single computer. You can add as many processors as you want, but unless you make them work symmetrically, two processors perform no faster than one. A server acting on the behalf of lots of clients is performing a lot of parallel tasks. The role of the operating system is to make sure those tasks get dispatched to the first available processor, but also to decide if they are to be preempted by a priority task. In the end, it's an exercise in scheduling.

[6]  Todo el capítulo 20 de la mencionada obra está dedicada al "multitasking" y "multithreading".  Aunque se refieren exclusivamente a los aspectos de programación multitarea y multihebra para Windows, es sin duda una buena fuente de información, con ejemplos detallados que incluyen la sincronización de hebras.