PDF de programación - C# Procesos y hebras

Procesos y hebras

En este capítulo utilizaremos la infraestructura que pone a nuestra disposición un sistema
operativo multitarea como Windows para dotar de paralelismo a nuestras aplicaciones, aun
cuando éstas se ejecuten en un PC convencional, en el que suele haber un único
microprocesador.

- Comenzaremos analizando los motivos que nos impulsan a la utilización de
hebras y procesos en nuestras aplicaciones, que no son siempre los primeros en
los que piensa la gente al hablar de concurrencia.

- A continuación, veremos cómo podemos ejecutar y controlar la ejecución de
procesos gracias a la clase System.Diagnostics.Process incluida en la
biblioteca de clases de la plataforma .NET.

- Acto seguido, pasaremos a estudiar el uso de múltiples hebras en el interior de un
proceso. En el caso de la plataforma .NET, la clase System.Thread nos
proporcionará la funcionalidad necesaria para construir aplicaciones multihebra.

- Finalmente, aprenderemos a usar mecanismos de sincronización que nos
permitirán coordinar el
trabajo realizado en distintas hebras. En capítulos
posteriores, examinaremos con mayor detenimiento algunos de los mecanismos de
comunicación entre procesos más utilizados.

8

Desarrollo Profesional de Aplicaciones con C#

Procesos y hebras

¿Por qué usar hebras y procesos? .......................................9

Procesos ................................................................................15
Ejecución de procesos............................................. 15
Finalización de procesos ......................................... 19
Monitorización de procesos ..................................... 21
Operaciones de E/S................................................. 25

Hebras ....................................................................................28
La clase Thread ....................................................... 28
Ejecución asíncrona de delegados .......................... 34
Hebras en aplicaciones Windows ............................ 36
Control de la ejecución de una hebra ...................... 39
Interrupción de la ejecución de una hebra............... 42

Mecanismos de sincronización............................................44
Acceso a recursos compartidos............................... 44
Monitores ................................................................. 45
Cerrojos: La sentencia lock...................................... 47
Otros mecanismos de sincronización ...................... 52
Operaciones asíncronas .......................................... 54

Referencias ............................................................................58

© Fernando Berzal, Francisco J. Cortijo & Juan Carlos Cubero

Procesos y hebras

9

¿Por qué usar hebras y procesos?

Los programas secuenciales que constan de una única hebra de control resultan más fáciles de
implementar y depurar que los programas con múltiples hebras que comparten, entre otros
recursos, un mismo espacio de memoria. Eso resulta evidente. En el caso de existir
paralelismo, ya sea a través de procesos independientes o mediante hebras dentro de un
proceso, la ejecución de un programa no es determinista porque depende del tiempo de CPU
que le asigna el sistema operativo a cada hebra. Como mencionamos en la introducción de
esta parte del libro, el no determinismo introducido por el entrelazado de las operaciones de
las distintas hebras provoca la aparición de errores difíciles de detectar y más aún de corregir.
En definitiva, que la vida del programador resultaría mucho más sencilla si no hiciese falta la
concurrencia.

Cuando la concurrencia se hace necesaria...

Supongamos que nuestra aplicación tiene que ocuparse de la realización de copias de
seguridad de los datos con los que trabaja. Con una única hebra tendríamos que programar
las copias de seguridad fuera del horario habitual de trabajo. ¿Y si el sistema tiene que
funcionar las 24 horas del día? Con el uso de hebras, podemos aprovechar los períodos de
inactividad de la CPU para ir haciendo la copia de seguridad mientras nuestra aplicación
sigue funcionando de cara a sus usuarios.

Imaginemos ahora que nuestra aplicación se encarga de registrar las transacciones efectuadas
en las cuestas de un banco (que pueden realizarse a cualquier hora del día gracias a los
cajeros automáticos y las tarjetas de crédito). Además, las copias de seguridad han de
realizarse muy a menudo, puede que de hora en hora. Para hacer una copia de seguridad,
primero habrá que empaquetar los datos (en un archivo ZIP o algo así) y después
transmitirlos a un lugar seguro (tal vez, en un refugio alojado en una cueva dentro de una
montaña de granito, como hacen algunas empresas de cierta envergadura). Si en preparar los
datos se tardan 30 minutos y, en enviarlos, otros 45 minutos, puede que de primeras nos
inclinemos a pensar que la copia de seguridad no se puede hacer con la frecuencia solicitada
(esto es, cada hora). O... ¿tal vez sí? Si dejamos encargada a una hebra/proceso de
empaquetar los datos, a los 30 minutos podremos comenzar su transmisión en otra
hebra/proceso, que requerirá otros 45 minutos para terminar la operación la primera vez. Una
hora y cuarto en total. Sin embargo, mientras se están transmitiendo los datos, podemos
comenzar a empaquetar los datos necesarios para la siguiente transmisión, de forma que
cuando termine la transmisión actual tengamos ya preparados los datos correspondientes a la
siguiente copia de seguridad. Algo para lo que, en principio, necesitaríamos una hora y
cuarto, ahora, gracias al uso de paralelismo, somos capaces de hacerlo cada tres cuartos de
hora. Menos incluso de lo que nos habían pedido y sin tener que cambiar el hardware ni
contratar más ancho de banda.

http://csharp.ikor.org/

10

Desarrollo Profesional de Aplicaciones con C#

Aunque el ejemplo anterior pueda inducir a pensar lo contrario, el uso de paralelismo
mediante la utilización de hebras y procesos es algo más común de lo que nos podemos
imaginar. La ejecución concurrente de procesos y hebras proporciona una amplia serie de
ventajas frente a las limitaciones de los antiguos sistemas monotarea.

El diseño correcto de una aplicación concurrente puede permitir que un programa complete
una mayor cantidad de trabajo en el mismo período de tiempo (como sucedía en el ejemplo
antes mencionado) pero también sirve para otros menesteres más mundanos, desde la creación
de interfaces que respondan mejor a las órdenes del usuario hasta la creación de aplicaciones
que den servicio a varios clientes (como puede ser cualquier aplicación web a la que varios
usuarios pueden acceder simultáneamente). En los siguientes párrafos intentaremos poner de
manifiesto los motivos que nos pueden conducir al uso de hebras y procesos en nuestras
aplicaciones.

De cara al usuario

El principal objetivo del uso de hebras o procesos es mejorar el rendimiento del sistema, y
éste no siempre se mide en la cantidad de trabajo que se realiza por unidad de tiempo. De
hecho, el uso de hebras se usa a menudo para reducir el tiempo de respuesta de una
aplicación. En otras palabras, se suelen utilizar hebras para mejorar la interfaz de usuario.

Aunque pueda resultar sorprendente, el usuario es el principal motivo por el que utilizaremos
hebras en nuestras aplicaciones con cierta asiduidad. Cuando una aplicación tiene que realizar
alguna tarea larga, su interfaz debería seguir respondiendo a las órdenes que el usuario
efectúe. La ventana de la aplicación debería refrescarse y no quedarse en blanco (como pasa
demasiado a menudo). Los botones existentes para cancelar una operación deberían cancelar
la operación de un modo inmediato (y no al cabo de un rato, cuando la operación ya ha
terminado de todos modos).

Jakob Nielsen, por ejemplo, en su libro Usability Engineering, sugiere que cualquier
operación que se pueda efectuar en una décima de segundo puede considerarse inmediata, por
lo que no requerirá mayor atención por nuestra parte al implementar la aplicación. Cuando
una operación se puede realizar por completo en un segundo, se puede decir que no
interrumpe demasiado el trabajo del usuario, si bien resulta conveniente utilizar, al menos,
una barra de progreso. Sin embargo, en operaciones que tarden varios segundos, el usuario
difícilmente mantendrá su atención y será aconsejable que nuestra aplicación sea capaz de
efectuar la operación concurrentemente con otras tareas.

En demasiadas ocasiones, las aplicaciones no le prestan atención debida al usuario. Mientras
están ocupadas haciendo algo, no responden como debieran a las solicitudes que realiza el
usuario. Con frecuencia, además, la aplicación no responde pese a que lo que queramos hacer
no tenga nada que ver con la tarea que nos está obstaculizando el trabajo. Estos bloqueos
temporales se suelen deber a que la aplicación está programada con una única hebra y,
mientras dura una operación costosa, esa hebra bloquea todo lo demás, congelando la interfaz

© Fernando Berzal, Francisco J. Cortijo & Juan Carlos Cubero

Procesos y hebras

11

de usuario. Afortunadamente, el uso de múltiples hebras puede mejorar enormemente la
satisfacción del usuario al manejar nuestras aplicaciones al permitirle continuar su trabajo sin
interrupciones.

Un ejemplo típico es el caso de una aplicación con una interfaz gráfica de usuario, en la que
hebras o procesos independientes pueden encargarse de realizar las operaciones costosas
mientras que la hebra principal de la aplicación sigue gestionando los eventos procedientes de
la interfaz de usuario.

De hecho, cuando una operación que ha de realizarse como respuesta a un evento es costosa,
es recomendable crear una hebra independiente para realizar dicha operación. De ese modo, el
control de la aplicación vuelve a manos del usuario de forma inmediata y se mejora
notablemente el tiempo de respuesta de la aplicación, su latencia de cara al usuario. Cualquier
operación que pueda bloquear nuestra aplicación durante un período de t