You are on page 1of 42

Tema 1.

Programacin Multiproceso

Pgina 1 de 42

Tema 1. Programacin Multiproceso


1. Recordando cmo programar en Java y el uso de NetBeans.....................................2
1.1. Enlaces. Recursos web..................................................................................................................2

2. Introduccin: Aplicaciones, Ejecutables y Procesos...................................................... 3


2.1. Ejecutables. Tipos......................................................................................................................... 4

3. Gestin de procesos........................................................................................................................ 5
3.1. Gestin de procesos. Introduccin.............................................................................................6
3.2. Estados de un Proceso.................................................................................................................. 6
3.3. Planificacin de procesos por el Sistema Operativo..............................................................8
3.3.1. Planificacin de procesos por el Sistema Operativo (II)....................................................... 9
3.3.1.1.Enlaces. Recursos web....................................................................................................... 9
3.4. Cambio de contexto en la CPU.................................................................................................10
3.5. Servicios. Hilos............................................................................................................................. 11
3.6. Creacin de procesos.................................................................................................................. 12
3.7. Comandos para la gestin de procesos................................................................................... 14
3.8. Herramientas grficas para la gestin de procesos............................................................. 16
4. Programacin concurrente....................................................................................................... 17
4.1. Para qu concurrencia?........................................................................................................... 18
4.2. Condiciones de competencia..................................................................................................... 19
5. Comunicacin entre procesos.................................................................................................. 19
5.1. Mecanismos bsicos de comunicacin.................................................................................... 21
5.2. Tipos de comunicacin............................................................................................................... 22
6. Sincronizacin entre procesos................................................................................................. 23
6.1. Regiones crticas.......................................................................................................................... 24
6.1.1. Categora de proceso cliente-suministrador......................................................................... 25
6.2. Semforos......................................................................................................................................26
6.3. Monitores...................................................................................................................................... 28
6.3.1. Monitores: Lecturas y escrituras bloqueantes en recursos compartidos.......................... 29
6.4. Memoria compartida..................................................................................................................30
6.5. Cola de mensajes..........................................................................................................................31
7. Requisitos: seguridad, vivacidad, eficiencia y reusabilidad..................................... 32
7.1. Arquitecturas y patrones de diseo.........................................................................................33
7.2. Documentacin............................................................................................................................ 35
7.3. Dificultades en la depuracin................................................................................................... 37
8. Programacin paralela y distribuida...................................................................................38
8.1. Conceptos bsicos........................................................................................................................39
8.2. Tipos de paralelismo................................................................................................................... 41
8.3. Modelos de infraestructura para programacin distribuida............................................ 42

Tema 1. Programacin Multiproceso

Pgina 2 de 42

1. Recordando cmo programar en Java y el uso de NetBeans.


La tecnologa Java es:

Lenguaje de programacin Java es un lenguaje de alto nivel, orientado a objetos. El lenguaje


es inusual porque los programas Java son tanto compilados como interpretados. La
compilacin traduce el cdigo Java a un lenguaje intermedio llamado Java bytecode. El
Bytecode, es analizado y ejecutado (interpretado) por Java Virtual Machine (JVM)un traductor
entre bytecode, el sistema operativo subyacente y el hardware. Todas las implementaciones del
lenguaje de programacin deben emular JVM, para permitir que los programas Java se ejecuten en
cualquier sistema que tenga una versin de JVM.

La plataforma Java es una plataforma slo de software que se ejecuta sobre varias plataformas
de hardware. Est compuesto por JVM y la interfaz de programacin de aplicaciones (API) Java
un amplio conjunto de componentes de software (clases) listos para usar que facilitan el desarrollo
y despliegue de applets y aplicaciones. La API Java abarca desde objetos bsicos a conexin en
red, seguridad, generacin de XML y servicios web. Est agrupada en bibliotecasconocidas
como paquetesde clases e interfaces relacionadas.
Versiones de la plataforma:

Java SE (Plataforma Java, Standard Edition). Permite desarrollar y desplegar


aplicaciones Java en desktops y servidores, como tambin en entornos empotrados y en tiempo
real.

Java EE (Plataforma Java, Enterprise Edition). La versin empresarial ayuda


a desarrollar y desplegar aplicaciones Java en el servidor portables, robustas, escalables y
seguras.

Java ME (Plataforma Java, Micro Edition).

Proporciona un entorno para


aplicaciones que operan en una gama amplia de dispositivos mviles y empotrados, como
telfonos mviles, PDA, STB de TV e impresoras.

Para la implementacin y desarrollo de aplicaciones, nos servimos de un IDE (Entorno Integrado


de Desarrollo), que es un programa informtico formado por distintas herramientas de programacin;
como son: editor, complilador, intrprete, depurador, control de versiones,

1.1.

Enlaces. Recursos web

En el siguiente enlace encontrars las instrucciones para la instalacin del IDE NetBeans; as
como enlaces para la descarga el IDE. Como te dars cuenta, no son las instrucciones de instalacin de las
ltimas versiones del IDE, pero stas estn en castellano. Tambin podrs consultar las instrucciones para
las ltimas versiones, en ingls.
Enlace a las instrucciones de instalacin del IDE NetBeans.
URL: http://NetBeans.org/community/releases/61/install_es.html
Ttulo: En este enlace puedes ver las instrucciones de instalacin del IDE NetBeans.
En cuanto a cmo manejar el entorno, a continuacin encontrars dos enlaces a manuales; y siempre
tendrs el recurso de los videotutoriales en youtube.com.
Enlace a la seccin de manuales oficiales de NetBeans.
URL: http://NetBeans.org/kb/index.html
Ttulo: En este enlace puedes acceder a la seccin de documentacin y soporte NetBeans.

Tema 1. Programacin Multiproceso

Pgina 3 de 42

Enlace a un manual sencillo para entender el IDE NetBeans.


URL: http://NetBeans.org/project_downloads/usersguide/Using_NetBeans55.pdf
Ttulo: En este enlace puedes descargar un documento, que est en ingls, pero contiene muchas capturas
y utiliza un lenguaje muy sencillo, que lo hace muy fcil de entender. [pdf -876KB]
Enlace a un ejemplo de vdeo tutorial sobre programacin en java con NetBeans.
URL: http://www.youtube.com/watch?v=zLcYPrYAKSA
Ttulo: En este enlace puedes ver el vdeo tutorial 'Java bsico con NetBeans'. Ejemplo de buenos vdeo
tutoriales que podrs encontrar en Internet.
Nos queda repasar la sintaxis del lenguaje Java. Un par de enlaces en los que puedes encontrar
buenos manuales para refrescar la sintaxis de java.
Enlace al tutorial 'Aprenda Java como si estuviera en primero'.
URL: http://ocw.uc3m.es/ingenieria-informatica/programacion/manuales
Ttulo: En este enlace puedes ver el tutorial 'Aprenda Java como si estuviera en primero'.
Enlace al tutorial 'Aprendiendo Java'.
URL: http://www.compunauta.com/forums/linux/programacion/java/ebook.html
Ttulo: En este enlace puedes descargar el tutorial 'Aprendiendo Java'.

PARA SABER MS
La tecnologa Java, actualmente abarca gran cantidad de herramientas y conceptos. En este
enlace puedes ampliar tus conocimientos sobre esta tecnologa.
Texto enlace: Ampliar informacin sobre la tecnologa Java.
URL: http://www.ibm.com/developerworks/ssa/java/newto/index.html
Ttulo: Enlace a la web de IBM, que recopila un buen resumen introductorio a la tecnologa
Java.

2. Introduccin: Aplicaciones, Ejecutables y Procesos.


CASO PRCTICO.
Aplicaciones, ejecutables y procesos? Son lo mismo o cosas
distintas? Tres palabras distintas para lo mismo?
A simple vista, parece que con los trminos aplicacin, ejecutable y proceso, nos estamos
refiriendo a lo mismo. Pero, no olvidemos que en los mdulos de primero hemos aprendido a
diferenciarlos.
Una aplicacin es un tipo de programa informtico, diseado como herramienta para resolver de
manera automtica un problema especfico del usuario.
Debemos darnos cuenta de que sobre el hardware del equipo, todo lo que se ejecuta son programas
informticos, que, ya sabemos, que se llama software. Con la definicin de aplicacin anterior, buscamos
diferenciar las aplicaciones, de otro tipo de programas informticos, como pueden ser: los sistemas
operativos, las utilidades para el mantenimiento del sistema, o las herramientas para el desarrollo de
software. Por lo tanto, son aplicaciones, aquellos programas que nos permiten editar una imagen, enviar
un correo electrnico, navegar en Internet, editar un documento de texto, chatear, etc.
Recordemos, que un programa es el conjunto de instrucciones que ejecutadas en un ordenador
realizarn una tarea o ayudarn al usuario a realizarla. Nosotros, como programadores y programadoras,
creamos un programa, escribiendo su cdigo fuente; con ayuda de un compilador, obtenemos su cdigo

Tema 1. Programacin Multiproceso

Pgina 4 de 42

binario o interpretado. Este cdigo binario (cdigo mquina) o interpretado, lo guardamos en un fichero.
Este fichero, es un fichero ejecutable, llamado comnmente: ejecutable o binario.
Un ejecutable es un fichero que contiene el cdigo binario o interpretado que ser ejecutado en un
ordenador.
Ya tenemos ms clara la diferencia entre aplicacin y ejecutable. Ahora, qu es un proceso? De
forma sencilla, un proceso, es un programa en ejecucin. Pero, es ms que eso, un proceso en el sistema
operativo (SO), es una unidad de trabajo completa; y, el SO gestiona los distintos procesos que se
encuentren en ejecucin en el equipo. En siguientes apartados de esta unidad trataremos ms en
profundidad todo lo relacionado con los procesos y el SO. Lo ms importante, es que diferenciemos que
un ejecutables es un fichero y un proceso es una entidad activa, el contenido del ejecutable,
ejecutndose.
Un proceso existe mientras que se est ejecutando una aplicacin. Es ms, la ejecucin
de una aplicacin, puede implicar que se arranquen varios procesos en nuestro equipo; y puede
estar formada por varios ejecutables y libreras.
Una aplicacin es un tipo de programa informtico, diseado como herramienta para
resolver de manera automtica un problema especfico del usuario. Al instalarla en el equipo, podremos
ver que puede estar formada por varios ejecutables y libreras. Siempre que lancemos la ejecucin de una
aplicacin, se crear, al menos, un proceso nuevo en nuestro sistema.

2.1.

Ejecutables. Tipos.

CASO PRCTICO.
Cmo reconocemos un ejecutable? Antes hemos hecho referencia a ejecutables que contenan cdigo
binario o interpretado. Sabes qu significa eso? Son todos los ficheros ejecutables iguales?
En sistemas operativos Windows, podemos reconocer un fichero ejecutable, porque su extensin,
suele ser .exe. En otros sistemas operativos, por ejemplo, los basados en GNU/Linux, los ficheros
ejecutables se identifican como ficheros que tienen activado su permiso de ejecucin (y no tienen que
tener una extensin determinada).
Segn el tipo de cdigo que contenga un ejecutable, los podemos clasificar en:

Binarios o cdigo mquina. Formados por un conjunto de instrucciones que


directamente son ejecutadas por el procesador del ordenador. Este cdigo se obtiene
al compilar el cdigo fuente de un programa y se guarda en un fichero ejecutable.
Este cdigo slo se ejecutar correctamente en equipos cuya plataforma sea
compatible con aquella para la que ha sido compilado (no es multiplataforma).
Ejemplos son, ficheros que obtenemos al compilar un ejecutable de C o C++.

Interpretados. Cdigo que suele tratarse como un ejecutable, pero no es


cdigo binario, sino otro tipo de cdigo, que en Java, por ejemplo se
llama bytecode. Est formado por cdigos de operacin que tomar el
intrprete (en el caso de Java, el intrprete es la mquina virtual Java o
JRE). Ese intrprete ser el encargado de traducirlos al lenguaje
mquina que ejecutar el procesador. El cdigo interpretado es ms
susceptible de ser multiplataforma o independiente de la mquina fsica en la que se haya
compilado.
Un tipo especial de ejecutables interpretados, son los llamados scripts.
Estos ficheros, contienen las instrucciones que sern ejecutadas una
detrs de otra por el intrprete. Se diferencian de otros lenguajes
interpretados porque no son compilados. Por lo que los podremos abrir

Tema 1. Programacin Multiproceso

Pgina 5 de 42

y ver el cdigo que contienen con un editor de texto plano (cosa que no pasa con los binarios e
interpretados compilados). Los intrpretes de este tipo de lenguajes se suelen llamar motores.
Ejemplos de lenguajes de script son: JavaScript, php, JSP, ASP, python, ficheros .BAT en MSDOS, Powershell en Windows, bash scripts en GNU/Linux,

Libreras. Conjunto de funciones que permiten dar modularidad y reusabilidad a nuestros


programas. Las hemos incluido en esta clasificacin, porque su contenido es cdigo ejecutable,
aunque ese cdigo sea ejecutado por todos los programas que invoquen las funciones que
contienen. El conjunto de funciones que incorpora una librera suele ser altamente reutilizable y
til para los programadores; evitando que tengan que reescribir una y otra vez el cdigo que
realiza la misma tarea. Ejemplo de libreras son: las libreras estndar de C, los paquetes
compilados DLL en Windows; las API (Interfaz de Programacin de Aplicaciones), como la J2EE
de Java (Plataforma Java Enterprise Edition versin 2); las libreras que incorpora el framework
de .NET; etc.

3. Gestin de procesos.
Como sabemos, en nuestro equipo, se estn ejecutando al mismo tiempo, muchos procesos. Por
ejemplo, podemos estar escuchando msica con nuestro reproductor multimedia favorito; al mismo
tiempo, estamos programando con NetBeans; tenemos el navegador web abierto, para ver los contenidos
de esta unidad; incluso, tenemos abierto el Messenger para chatear con nuestros amigos y amigas.
Independientemente de que el microprocesador de nuestro equipo sea ms o menos moderno (con
uno o varios ncleos de procesamiento), lo que nos interesa es que actualmente, nuestros SO son
multitarea; como son, por ejemplo, Windows y GNU/Linux. Ser multitarea es, precisamente, permitir que
varios procesos puedan ejecutarse al mismo tiempo, haciendo que todos ellos compartan
el ncleo o ncleos del procesador. Pero, cmo? Imaginemos que nuestro equipo, es
como nosotros mismos cuando tenemos ms de una tarea que realizar. Podemos, ir
realizando cada tarea una detrs de otra, o, por el contrario, ir realizando un poco de
cada tarea. Al final, tendremos realizadas todas las tareas, pero para otra persona que nos
est mirando desde fuera, le parecer que, de la primera forma, vamos muy lentos (y ms, si est
esperando el resultado de una de las tareas que tenemos que realizar); sin embargo, de la segunda forma,
le parecer que estamos muy ocupados, pero que poco a poco estamos haciendo lo que nos ha pedido.
Pues bien, el micro, es nuestro cuerpo, y el SO es el encargado de decidir, por medio de la gestin de
procesos, si lo hacemos todo de golpe, o una tarea detrs de otra.
En este punto, es interesante que hagamos una pequea clasificacin de los tipos de procesos que
se ejecutan en el sistema:
Por lotes. Estn formados por una serie de tareas, de las que el usuario slo est interesado en el
resultado final. El usuario, slo introduce las tareas y los datos iniciales, deja que se realice todo el
proceso y luego recoge los resultados. Por ejemplo: enviar a imprimir varios documentos,
escanear nuestro equipo en busca de virus,...
Interactivos. Aquellas tareas en las que el proceso interacta continuamente con el usuario y acta
de acuerdo a las acciones que ste realiza, o a los datos que suministra. Por ejemplo: un
procesador de textos; una aplicacin formada por formularios que permiten introducir datos en
una base de datos; ...
Tiempo real. Tareas en las que es crtico el tiempo de respuesta del sistema. Por ejemplo: el
ordenador de a bordo de un automvil, reaccionar ante los eventos del vehculo en un tiempo
mximo que consideramos correcto y aceptable. Otro ejemplo, son los equipos que controlan los
brazos mecnicos en los procesos industriales de fabricacin.

Tema 1. Programacin Multiproceso

3.1.

Pgina 6 de 42

Gestin de procesos. Introduccin.

En nuestros equipos ejecutamos distintas aplicaciones interactivas y por lotes. Como sabemos, un
microprocesador es capaz de ejecutar miles de millones de instrucciones bsicas en un segundo (por
ejemplo, un i7 puede llegar hasta los 3,4 GHz). Un micro, a esa velocidad, es capaz de realizar muchas
tareas, y nosotros (muy lentos para l), apreciaremos que solo est ejecutando la aplicacin que nosotros
estamos utilizando. Al fin y al cabo, al micro, lo nico que le importa es ejecutar instrucciones y dar sus
resultados, no tiene conocimiento de si pertenecen a uno u otro proceso, para l son instrucciones. Es, el
SO el encargado de decidir qu proceso puede entrar a ejecutarse o debe esperar. Lo veremos ms
adelante, pero se trata de una fila en la que cada proceso coge un nmero y va tomando su turno de
servicio durante un periodo de tiempo en la CPU; pasado ese tiempo, vuelve a ponerse al final de la fila,
esperando a que llegue de nuevo su turno.
Vamos a ver cmo el SO es el encargado de gestionar los procesos, qu es realmente un programa
en ejecucin, qu informacin asocia el SO a cada proceso. Tambin veremos qu herramientas tenemos a
nuestra disposicin para poder obtener informacin sobre los procesos que hay en ejecucin en el sistema
y qu uso estn haciendo de los recursos del equipo.
Los nuevos micros, con varios ncleos, pueden, casi totalmente, dedicar una CPU a la ejecucin
de uno de los procesos activos en el sistema. Pero no nos olvidemos de que adems de estar activos los
procesos de usuario, tambin se estar ejecutando el SO, por lo que seguir siendo necesario repartir los
distintos ncleos entre los procesos que estn en ejecucin.

3.2.

Estados de un Proceso.

Si el sistema tiene que repartir el uso del microprocesador entre los distintos procesos, qu le
sucede a un proceso cuando no se est ejecutando? Y, si un proceso est esperando datos, por qu el
equipo hace otras cosas mientras que un proceso queda a la espera de datos?
Veamos con detenimiento, cmo es que el SO controla la ejecucin de los procesos. Ya
comentamos en el apartado anterior, que el SO es el encargado de la gestin de procesos. En el siguiente
grfico, podemos ver un esquema muy simple de cmo podemos planificar la ejecucin de varios
procesos en una CPU.

En este esquema, podemos ver:


1. Los procesos nuevos, entran en la cola de procesos activos en el sistema.
2. Los procesos van avanzando posiciones en la cola de procesos activos, hasta que les toca el turno
para que el SO les conceda el uso de la CPU.
3. El SO concede el uso de la CPU, a cada proceso durante un tiempo determinado y equitativo, que
llamaremos quantum. Un proceso que consume su quantum, es pausado y enviado al final de la
cola.
4. Si un proceso finaliza, sale del sistema de gestin de procesos.

Tema 1. Programacin Multiproceso

Pgina 7 de 42

Esta planificacin que hemos descrito, resulta equitativa para todos los procesos (todos van a ir
teniendo su quantum de ejecucin). Pero se nos olvidan algunas situaciones y caractersticas de nuestros
procesos:

Cuando un proceso, necesita datos de un archivo o una entrada de datos que deba suministrar el
usuario; o, tiene que imprimir o grabar datos; cosa que llamamos 'el proceso est en una operacin
de entrada/salida' (E/S para abreviar). El proceso, queda bloqueado hasta que haya finalizado esa
E/S. El proceso es bloqueado, porque, los dispositivos son mucho ms lentos que la CPU, por lo
que, mientras que uno de ellos est esperando una E/S, otros procesos pueden pasar a la CPU y
ejecutar sus instrucciones. Cuando termina la E/S que tenga un proceso bloqueado, el SO, volver
a pasar al proceso a la cola de procesos activos, para que recoja los datos y contine con su tarea
(dentro de sus correspondientes turnos).

Slo mencionar (o recordar), que cuando la memoria RAM del equipo est llena, algunos procesos
deben pasar a disco (o almacenamiento secundario) para dejar espacio en RAM que permita la
ejecucin de otros procesos.

Importante: Todo proceso en ejecucin, tiene que estar cargado en la RAM fsica del equipo o memoria
principal, as como todos los datos que necesite.

Hay procesos en el equipo cuya ejecucin es crtica para el sistema, por lo que, no siempre pueden
estar esperando a que les llegue su turno de ejecucin, haciendo cola. Por ejemplo, el propio SO es
un programa, y por lo tanto un proceso o un conjunto de procesos en ejecucin. Se le da prioridad,
evidentemente, a los procesos del SO, frente a los procesos de usuario.

Con todo lo anterior, podemos quedarnos con los siguientes estados en el ciclo de vida de un proceso:
1.
2.
3.
4.
5.

Nuevo. Proceso nuevo, creado.


Listo. Proceso que est esperando la CPU para ejecutar sus instrucciones.
En ejecucin. Proceso que actualmente, est en turno de ejecucin en la CPU.
Bloqueado. Proceso que est a la espera de que finalice una E/S.
Suspendido. Proceso que se ha llevado a la memoria virtual para liberar, un poco, la RAM del
sistema.
6. Terminado. Proceso que ha finalizado y ya no necesitar ms la CPU.
El siguiente grfico, nos muestra las distintas transiciones que se producen entre uno u otro estado:

suspendido : se queda sin memoria ram

Tema 1. Programacin Multiproceso

3.3.

Pgina 8 de 42

Planificacin de procesos por el Sistema Operativo.

Entonces, un proceso sabe cuando tiene o no la CPU? Cmo se decide qu proceso debe
ejecutarse en cada momento?
Hemos visto que un proceso, desde su creacin hasta su fin (durante su vida), pasa por muchos
estados. Esa transicin de estados, es transparente para l, todo lo realiza el SO. Desde el punto de vista
de un proceso, l siempre se est ejecutando en la CPU sin esperas. Dentro de la gestin de procesos
vamos a destacar dos componentes del SO que llevan a cabo toda la tarea: el cargador y el planificador.
El cargador es el encargado de crear los procesos. Cuando se inicia un proceso (para cada proceso), el
cargador, realiza las siguientes tareas:
1) Carga el proceso en memoria principal. Reserva un espacio en la RAM para el proceso. En ese
espacio, copia las instrucciones del fichero ejecutable de la aplicacin, las constantes y, deja un
espacio para los datos (variables) y la pila (llamadas a funciones). Un proceso, durante su
ejecucin, no podr hacer referencia a direcciones que se encuentren fuera de su espacio de
memoria; si lo intentara, el SO lo detectar y generar una excepcin (produciendo, por ejemplo,
los tpicos pantallazos azules de Windows).

todos los procesos


tienen distinto tamao
llamada funcion

guarda principal los registros de la cpu

2) Crea una estructura de informacin llamada PCB (Bloque de Control de Proceso). La


informacin del PCB, es nica para cada proceso y permite controlarlo. Esta informacin, tambin
la utilizar el planificador. Entre otros datos, el PCB estar formado por:

Identificador del proceso o PID. Es un nmero nico para cada proceso, como un DNI de
proceso.

Estado actual del proceso: en ejecucin, listo, bloqueado, suspendido, finalizando.

Espacio de direcciones de memoria donde comienza la zona de memoria reservada al proceso


principal
y su tamao.

Informacin para la planificacin: prioridad, quamtum, estadsticas, ... prioridad grande , tiempo real etc

Informacin para el cambio de contexto: valor de los registros de la CPU, entre ellos el
contador de programa y el puntero a pila. Esta informacin es necesaria para poder cambiar de
la ejecucin de un proceso a otro.

Recursos utilizados. Ficheros abiertos, conexiones,

Tema 1. Programacin Multiproceso

3.3.1.

Pgina 9 de 42

Planificacin de procesos por el Sistema Operativo (II).

Una vez que el proceso ya est cargado en memoria, ser el planificador el encargado de tomar las
decisiones relacionadas con la ejecucin de los procesos. Se encarga de decidir qu proceso se ejecuta y
cunto tiempo se ejecuta. El planificador es otro proceso que, en este caso, es parte del SO. La poltica en
la toma de decisiones del planificador se denominan: algoritmo de planificacin. Los ms importantes
son:
algoritmo hibrido
Round-Robin. Este algoritmo de planificacin favorece la ejecucin de procesos interactivos. Es
aqul en el que cada proceso puede ejecutar sus instrucciones en la CPU durante un quamtum. Si
no le ha dado tiempo a finalizar en ese quamtum, se coloca al final de la cola de procesos listos, y
espera a que vuelva su turno de procesamiento. As, todos los procesos listos en el sistema van
ejecutndose poco a poco.
mas realista , sistema operativos

Por prioridad. En el caso de Round-Robin, todos los procesos son tratados por igual. Pero existen
procesos importantes, que no deberan esperar a recibir su tiempo de procesamiento a que
finalicen otros procesos de menor importancia. En este algoritmo, se asignan prioridades a los
distintos procesos y la ejecucin de estos, se hace de acuerdo a esa prioridad asignada. Por
ejemplo: el propio planificador tiene mayor prioridad en ejecucin que los procesos de usuario,
, hasta que no termina la primera de las colas , no se puede ejecutar las
no crees? los procesos con distintas prioridad , multiples colas demas colas

Mltiples colas. Es una combinacin de los dos anteriores y


el implementado en los sistemas operativos actuales. Todos
los procesos de una misma prioridad, estarn en la misma
cola. Cada cola ser gestionada con el algoritmo RoundRobin. Los procesos de colas de inferior prioridad no pueden
ejecutarse hasta que no se hayan vaciado las colas de
procesos de mayor prioridad.

orden de prioridad

En la planificacin (scheduling) de procesos se busca conciliar los


siguientes objetivos:
Equidad. Todos los procesos deben poder ejecutarse.
Eficacia. Mantener ocupada la CPU un 100% del tiempo.
Tiempo de respuesta. Minimizar el tiempo de respuesta al usuario.
Tiempo de regreso. Minimizar el tiempo que deben esperar los usuarios de procesos por lotes para
obtener sus resultados.
Rendimiento. Maximizar el nmero de tareas procesadas por hora.
3.3.1.1. Enlaces. Recursos web.

En el siguiente enlace puedes ver una simulacin del algoritmo de planificacin Round-Robin, en l
podrs ver cmo los procesos van tomando su turno de ejecucin en la CPU hasta su finalizacin.
http://wwwdi.ujaen.es/~lina/TemasSO/PLANIFICACIONDEPROCESOS/PlanificadorProcesos/Planifica
dorProcesosRR.html
En este enlace puedes ver cmo los procesos van tomando su turno de ejecucin en la CPU hasta su
finalizacin.
http://wwwdi.ujaen.es/~lina/TemasSO/PLANIFICACIONDEPROCESOS/PlanificadorProcesos/alg_plani
f_RR.html

Tema 1. Programacin Multiproceso

Pgina 10 de 42

REFLEXIONA.
En la plataforma Java, todos los procesos se ejecutan sobre esa mquina?, quin es el que gestiona los
procesos java, el SO o la mquina virtual?
La respuesta a estas preguntas, las veremos en un ejemplo ms adelante.

3.4.

Cambio de contexto en la CPU.

un proceso deja de ejecutar y empieza a ejecutar otro

CASO PRCTICO.
Una CPU ejecuta instrucciones, independientemente del proceso al que
pertenezcan. Entonces, cmo consigue unas veces ejecutar las
instrucciones de un proceso y luego de otro y otro y otro..., sin que se
mezclen los datos de unos con otros?

Un proceso es una unidad de trabajo completa. El sistema operativo es el encargado de


gestionar los procesos en ejecucin de forma eficiente, intentando evitar que haya conflictos en el uso que
hacen de los distintos recursos del sistema. Para realizar esta tarea de forma correcta, se asocia a cada
proceso un conjunto de informacin (PCB) y de unos mecanismos de proteccin (un espacio de
direcciones de memoria del que no se puede salir y una prioridad de ejecucin).
Imaginemos que, en nuestro equipo, en un momento determinado, podemos estar escuchando
msica, editando un documento, al mismo tiempo, chateando con otras personas y navegando en Internet.
En este caso, tendremos ejecutndose en el sistema cuatro aplicaciones distintas, que pueden ser: el
reproductor multimedia VLC, el editor de textos writer de OpenOffice, el Messenger y el navegador
Firefox. Todos ellos, ejecutados sin fallos y cada uno haciendo uso de sus datos.
El sistema operativo (el planificador), al realizar el cambio una aplicacin a otra, tiene que guardar
el estado en el que se encuentra el microprocesador y cargar el estado en el que estaba el microprocesador
cuando cort la ejecucin de otro proceso, para continuar con ese. Pero, qu es el estado de la CPU?
Una CPU, adems de circuitos encargados de realizar las operaciones con los datos (llamados circuitos
operacionales), tiene unas pequeos espacios de memoria (llamados registros), en los que se almacenan
temporalmente la informacin que, en cada instante, necesita la instruccin que est procesando la CPU.
El conjunto de registros de la CPU es su estado.
Entre los registros, destacamos el Registro Contador de Programa y el puntero a la pila.

El Contador de Programa, en cada instante almacena la direccin de la siguiente instruccin a


ejecutar. Recordemos, que cada instruccin a ejecutar, junto con los datos que necesite, es llevada
desde la memoria principal a un registro de la CPU para que sea procesada; y, el resultado de la
ejecucin, dependiendo del caso, se vuelve a llevar a memoria (a la direccin que ocupe la
correspondiente variable). Pues el Contador de Programa, apunta a la direccin de la siguiente
instruccin que habr que traer de la memoria, cuando se termine de procesar la instruccin en
curso. Este Contador de Programa nos permitir continuar en cada proceso por la instruccin en
dnde lo hubiramos dejado todo.

El Puntero a Pila, en cada instante apunta a la parte superior de la pila del proceso en ejecucin.
En la pila de cada proceso es donde ser almacenado el contexto de la CPU. Y de donde se
recuperar cuando ese proceso vuelva a ejecutarse.

Tema 1. Programacin Multiproceso

Pgina 11 de 42

La CPU realiza un cambio de contexto cada vez que


cambia la ejecucin de un proceso a otro distinto. En un
cambio de contexto, hay que guardar el estado actual de
la CPU y restaurar el estado de CPU del proceso que va
a pasar a ejecutar.

3.5.

Servicios. Hilos.

CASO PRCTICO.
La conclusin que estamos sacando, es, que todo lo que se ejecuta en un equipo es un programa y que,
cuando est en ejecucin, se llama proceso. Entones qu son los servicios? y los hilos?
En este apartado, haremos una breve introduccin a los conceptos servicio e hilo, ya que los
trataremos en profundidad en el resto de unidades de este mdulo. cambio de contexto de la cpu mas rapido entre hilos
que entre procesos

El ejemplo ms claro de hilo o thread, es un juego. El juego, es la aplicacin y,


mientras que nosotros controlamos uno de los personajes, los 'malos' tambin se
mueven, interactan por el escenario y quitan vida. Cada uno de los personajes del
juego es controlado por un hilo. Todos los hilos forman parte de la misma aplicacin,
cada uno acta siguiendo un patrn de comportamiento. El comportamiento es el
algoritmo que cada uno de ellos seguir. Sin embargo, todos esos hilos comparten la
informacin de la aplicacin: el nmero de vidas restantes, la puntuacin obtenida hasta eso momento, la
posicin en la que se encuentra el personaje del usuario y el resto de personajes, si ha llegado el final del
juego, etc. Como sabemos, esas informaciones son variables. Pues bien, un proceso, no puede acceder
directamente a la informacin de otro proceso. Pero, los hilos de un mismo proceso estn dentro de l, por
lo que comparten la informacin de las variables de ese proceso. cada personaje del juego es un hilo , la programa principal es
el hilo principal

Realizar cambios de contexto entre hilos de un mismo proceso, es ms rpido y menos


costoso que el cambio de contexto entre procesos, ya que slo hay que cambiar el valor del registro
contador de programa de la CPU y no todos los valores de los registros de la CPU.
DESTACADO.
Un proceso, estar formado por, al menos, un hilo de ejecucin.
Un proceso es una unidad pesada de ejecucin. Si el proceso tiene varios hilos, cada hilo, es una unidad de
ejecucin ligera.
PARA SABER MS
Sabes lo que es Hyper-Threading (HT)? Es una tecnologa patentada por Intel, que incorpor en sus
micros Pentium4 de un slo ncleo para que el propio micro (hardware) simulara la existencia de 2
ncleos lgicos, para obtener mayor productividad en procesos de ms de un hilo, ya que cada ncleo
lgico gestionar cada hilo de forma casi independiente. Esta tecnologa la elimin en sus Core 2 Duo y
Quad; ya que al existir ms de un ncleo hardware no haca falta simular la existencia de ms de un
ncleo por ncleo fsico. Y lo ha vuelto a introducir en su familia de microprocesadores i7, i5 e i3. Estos
ltimos, por cada ncleo fsico, simulan 2 ncleos lgicos. Buscan as incrementar la productividad del
micro.

Tema 1. Programacin Multiproceso

Pgina 12 de 42

Enlace en wikipedia.org a su entrada sobre Hyper-Threading.


URL: http://es.wikipedia.org/wiki/HyperThreading
Ttulo: El microprocesador ayuda en los cambios de contexto entre hilos con la tecnologa HyperThreading, podemos ampliar informacin con su entrada en Wikipedia.
Texto enlace: Enlace a un vdeo que muestra grficamente cmo funciona Hyper-threading (vdeo en
ingls).
URL: http://www.youtube.com/watch?v=kkrqyEpINSQ
Ttulo: En los nuevos micros i7 de Intel, podemos hacer ms en menos tiempo con su tecnologa HyperThreading.
Resumen vdeo: El vdeo muestra los cuatro ncleos de un procesador como si fueran canales de
procesamiento, por los que van pasando bolitas que son la representacin grfica de las instrucciones; y
esas bolitas van en fila una detrs de otra, que simula lo que sera un proceso. Sin Hyper-hreading, cada
ncleo slo procesa las instrucciones de un proceso una detrs de otra. Con Hyper-hreading, cada ncleo,
a nivel hardware, es capaz de ejecutar instrucciones pertenecientes a varios procesos entremezclando las
instrucciones ejecutadas, pero no los resultados. El resultado final, es que se incrementa la productividad
del procesador.
Un servicio es un proceso que, normalmente, es cargado durante el arranque del sistema
operativo. Recibe el nombre de servicio, ya que es un proceso que queda a la espera de que otro le
pida que realice una tarea. Por ejemplo, tenemos el servicio de impresin con su tpica cola de trabajos
a imprimir. Nuestra impresora imprime todo lo que recibe del sistema, pero se debe tener cuidado, ya que
si no se le envan los datos de una forma ordenada, la impresora puede mezclar las partes de un trabajo
con las de otro, incluso dentro del mismo folio. El servicio de impresin, es el encargado de ir enviando
los datos de forma correcta a la impresora para que el resultado sea el esperado. Adems, las impresoras,
no siempre tienen suficiente memoria para guardar todos los datos de impresin de un trabajo completo,
por lo que el servicio de impresin se los dar conforme vaya necesitndolos. Cuando finalice cada
trabajo, puede notificrselo al usuario. Si en la cola de impresin, no hay trabajos pendientes, el servicio
de impresin quedar a la espera y podr avisar a la impresora para que quede en StandBy.
Como este, hay muchos servicios activos o en ejecucin en el sistema, y no todos son servicios del
sistema operativo, tambin hay servicios de aplicacin, instalados por el usuario y que pueden lanzarse al
arrancar el sistema operativo o no, dependiendo de su configuracin o cmo los configuremos.
DESTACADO.
Un servicio, es un proceso que queda a la espera de que otros le pida que realice una
tarea.

3.6.

Creacin de procesos.

CASO PRCTICO.
En muchos casos necesitaremos que una aplicacin lance varios procesos. Esos procesos pueden
realizar cada uno una tarea distinta o todos la misma. Por ejemplo, imaginemos un editor de texto plano
sencillo. Estamos acostumbrados a que los distintos ficheros abiertos se muestren en pestaas
independientes, pero cmo implementamos eso?
Las clases que vamos a necesitar para la creacin de procesos, son:
Clase java.lang.Process. Proporciona los objetos Proceso, por los que podremos controlar los
procesos creados desde nuestro cdigo.
Clase java.lang.Runtime. Clase que permite lanzar la ejecucin de un programa en el sistema.
Sobre todos son interesantes los mtodos exec( ) de esta clase, por ejemplo:

Runtime.exec(String comando); devuelve un objeto Process que representa al proceso en

Tema 1. Programacin Multiproceso

Pgina 13 de 42

ejecucin que est realizando la tarea comando.


La ejecucin del mtodo exec() puede lanzar las excepciones: SecurityException, si hay
administracin de seguridad y no tenemos permitido crear subprocesos. IOException, si ocurre un error
de E/S. NullPointerException y IllegalArgumentException, si commando es una cadena nula o vaca.
Ejemplo de cdigo de creacin de procesos.
Si queremos editar varios ficheros de texto a la vez, necesitamos que sean creados tantos procesos
del editor de texto, como documentos queramos editar. Vamos a utilizar la aplicacin de ejemplo del IDE
NetBeans 'Editor de texto (Document Editor)', para que nos permita editar varios documentos al mismo
tiempo en distintas instancias del editor.
Recursos: Se te proporcionar el cdigo fuente de la aplicacin y una presentacin paso a paso para crear
el cdigo fuente en NetBeans.
documentEditor aplicacion que queremos ejecutar pero esta caducada

no tienes permisos para esa aplicacion

PARA SABER MS
Como siempre, es interesante consultar la documentacin de las clases y mtodos que hemos utilizado, ya
que nos permite sacar todo el partido de su funcionalidad.

1
Texto enlace: Documentacin sobre la clase java.lang.Process.
URL: http://download.oracle.com/javase/6/docs/api/java/lang/Process.html
Ttulo: Documentacin oficial en la web oracle de la clase java.lang.Process.
Texto enlace: Documentacin de la clase java.lang.Runtime.
URL: http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html
Ttulo: Documentacin oficial en la web oracle de la clase java.lang.Runtime; sobre todo es interesante consultar las
sobrecargas del mtodo exec de esta clase.
Texto enlace: Documentacin de la clase java.lang.ProcessBuilder.
URL: http://download.oracle.com/javase/6/docs/api/java/lang/ProcessBuilder.html
Ttulo: Documentacin oficial en la web oracle de la clase java.lang.ProcessBuilder; se trata de una clase que hace de
intermediaria entre Process y Runtime; til para invocar comandos del sistema operativo estableciendo el directorio de
ejecucin y parmetros adicionales (aunque todo se puede implementar con las clases anteriores).

Tema 1. Programacin Multiproceso

3.7.

Pgina 14 de 42

Comandos para la gestin de procesos.

CASO PRCTICO.
Comandos? Las interfaces grficas son muy bonitas e intuitivas, para qu quiero yo aprender
comandos?

Es cierto que podemos pensar que ya no necesitamos comandos. Y que podemos desterrar el
intrprete de comandos, terminal o shell. Hay mltiples motivos por los que esto no es as:

Necesitamos comandos para lanzar procesos en el sistema.


Adems de las llamadas al sistema, los comandos son una forma directa de pedirle al sistema
operativo que realice tareas por nosotros.
Construir correctamente los comandos, nos permitir comunicarnos con el sistema operativo y
poder utilizar los resultados de estos comandos en nuestras aplicaciones.
En GNU/Linux, existen programas en modo texto para realizar casi cualquier cosa. En muchos
casos, cuando utilizamos una interfaz grfica, sta es un frontend del programa en modo comando.
Este frontend, puede proporcionar todas o algunas de las funcionalidades de la herramienta real.
La administracin de sistemas, y ms si se realiza de forma remota, es ms eficiente en modo
comando. Las administradoras y administradores de sistemas experimentadas utilizan scripts y
modo comandos, tanto en sistemas Windows como GNU/Linux.

El comienzo en el mundo de los comandos, puede resultar aterrador, hay muchsimos comandos, es
imposible aprendrselos todos! Bueno, no nos alarmemos, con este par de trucos podremos defendernos:
1.
El nombre de los comandos suele estar relacionado con la tarea que realizan, slo que
expresado en ingls, o utilizando siglas. Por ejemplo: tasklist muestra un listado de los procesos en
sistemas Windows; y en GNU/Linux obtendremos el listado de los procesos con ps, que son las siglas
de 'process status'.
2.

Su sintaxis siempre tiene la misma forma:


nombreDelComando<espacioEnBlanco>opciones

Las opciones, dependen del comando en si. Podemos consultar el manual del comando antes de utilizarlo.
En GNU/Linux, lo podemos hacer con man nombreDelComando; y en Windows, con
nombreDelComando /?
Recuerda dejar siempre un espacio en blanco despus del nombreDelComando y entre las opciones.
Despus de esos pequeos apuntes, los comandos que nos interesa conocer para la gestin de procesos

Tema 1. Programacin Multiproceso

Pgina 15 de 42

son:
1. Windows. Este sistema operativo es conocido por sus interfaces grficas, el intrprete de
comandos conocido como Smbolo del sistema, no ofrece muchos comandos para la gestin de
procesos. Tendremos:
tasklist. Lista los procesos presentes en el sistema. Mostrar el nombre del ejecutable; su
correspondiente Identificador de proceso; y, el porcentaje de uso de memoria; entre otros datos.
taskkill. Mata procesos. Con la opcin /PID especificaremos el Identificador del proceso que
queremos matar.
2. GNU/Linux. En este sistema operativo, todo se puede realizar cualquier tarea en modo texto,
adems de que los desarrolladores y desarrolladoras respetan en la implementacin de las
aplicaciones, que sus configuraciones se guarden en archivos de texto plano. Esto es muy til para
las administradoras y administradores de sistemas.
ps. Lista los procesos presentes en el sistema. Con la opcin aux muestra todos los procesos del
sistema independientemente del usuario que los haya lanzado.
pstree. Muestra un listado de procesos en forma de rbol, mostrando qu procesos han creado
otros. Con la opcin AGu construir el rbol utilizando lneas gua y mostrar el nombre de
usuario propietario del proceso.
kill. Manda seales a los procesos. La seal -9, matar al proceso. Se utiliza kill -9 <PID>.
killall. Mata procesos por su nombre. Se utiliza como killall nombreDeAplicacion.
nice. Cambia la prioridad de un proceso. nice -n 5 comando ejecutar el comando con una
prioridad 5. Por defecto la prioridad es 0. Las prioridades estn entre -20 (ms alta) y 19 (ms
baja).
PARA SABER MS
Actualmente, est disponible un nuevo interfaz de comandos para los sistemas Windows denominado Powershell.
Incrementa la potencia que tiene el intrprete de comandos comn, as se recupera la potencia de los scripts de administracin.
En los sistemas Windows 7, ya viene preinstalado. Podemos lanzar su intrprete de comandos (Smbolo de Windows Todos
los programas Accesorios Windows Powershell) y aprender su sintaxis (un nuevo lenguaje de programacin).
Texto enlace: Pgina principal de Microsoft Windows Powershell.
URL: http://technet.microsoft.com/es-es/scriptcenter/dd742419.aspx
Ttulo: Enlace a la web technet.microsoft.com, en el que podrs acceder a los enlaces
de descarga de la herramienta Powershell y a gran cantidad de manuales.

Tema 1. Programacin Multiproceso

3.8.

Pgina 16 de 42

Herramientas grficas para la gestin de procesos.

CASO PRCTICO.
Pero, tenemos que hacerlo todo en modo comandos? qu nos permite hacer el Administrador de
tareas de Windows con los procesos? No hay ninguna herramienta grfica similar en los sistemas
GNU/Linux?

Tanto los sistemas Windows como GNU/Linux proporcionan herramientas grficas para la gestin
de procesos. En el caso de Windows, se trata del Administrador de tareas, y en GNU/Linux del
Monitor del sistema. Ambos, son bastante parecidos, nos ofrecen, al menos, las siguientes
funcionalidades e informacin:
Listado de todos los procesos que se encuentran activos en el sistema, mostrando su PID, usuario
y ubicacin de su fichero ejecutable.
Posibilidad de finalizar procesos.
Informacin sobre el uso de CPU, memoria principal y virtual, red,
Posibilidad de cambiar la prioridad de ejecucin de los procesos.
DEBES CONOCER
SysInternals, es un conjunto de utilidades avanzadas para SO Windows publicadas como freeware.
En particular, recomendamos las herramientas grficas Process Explorer y Process Monitor. Process
Explorer nos dar informacin ms completa sobre los procesos activos en el sistema; y Process
Monitor nos informar de la actividad (de E/S) de los procesos e hilos activos en el sistema: ficheros a
los que estn accediendo, actividad en red, creacin de hilos, etc.
Texto enlace: Acceder a la pgina con la recopilacin de utilidades para la gestin de procesos y subprocesos de SysInternals.
URL: http://technet.microsoft.com/es-es/sysinternals/bb795533
Ttulo: Enlace a la web technet.microsoft.com, para ver una recopilacin de utilidades para consultar los procesos en ejecucin
y los recursos que consumen.

Tema 1. Programacin Multiproceso

Pgina 17 de 42

4. Programacin concurrente.
Hasta ahora hemos programado aplicaciones secuenciales u orientadas a eventos. Siempre hemos
pensado en nuestras aplicaciones como si se ejecutaran de forma aislada en la mquina. De hecho, el SO
garantiza que un proceso no accede al espacio de trabajo (zona de memoria) de otro, esto es, unos
procesos no pueden acceder a las variables de otros procesos. Sin embargo, los procesos, en ocasiones,
necesitan comunicarse entre ellos, o necesitan acceder al mismo recurso (fichero, dispositivo, etc.). En
esas situaciones, hay que controlar la forma en la que esos
procesos se comunican o acceden a los recursos, para que
no haya errores, resultados incorrectos o inesperados.
Podemos ver la concurrencia como una carrera, en la
que todos los corredores corren al mismo tiempo buscando un
mismo fin, que es ganar la carrera. En el caso de los procesos,
competirn por conseguir todos los recursos que necesiten.
La definicin de concurrencia, no es algo sencillo.
En el diccionario, concurrencia es la coincidencia de varios sucesos al mismo tiempo.
Nosotros podemos decir que dos procesos son concurrentes, cuando la primera instruccin de
un proceso se ejecuta despus de la primera y antes de la ltima de otro proceso.
Por otro lado, hemos visto que los procesos activos se ejecutan alternando sus instantes de
ejecucin en la CPU. Y, aunque nuestro equipo tenga ms de un ncleo, los tiempos de ejecucin de cada
ncleo se repartirn entre los distintos procesos en ejecucin. La planificacin alternando los instantes
de ejecucin en la gestin de los procesos, hace que los procesos se ejecuten de forma concurrente. O
lo que es lo mismo: multiproceso = concurrencia.
La programacin concurrente proporciona mecanismos de comunicacin y sincronizacin
entre procesos que se ejecutan de forma simultanea en un sistema informtico. La programacin
concurrente nos permitir definir qu instrucciones de nuestros procesos se pueden ejecutar de forma
simultnea con las de otros procesos, sin que se produzcan errores; y cules deben ser sincronizadas con
las de otros procesos para que los resultados de sean correctos.
En el resto de la unidad pondremos especial cuidado en estudiar cmo solucionar los conflictos
que pueden surgir cuando dos o ms procesos intentan acceder al mismo recurso de forma
concurrente.
PARA SABER MS.
La naturaleza y los modelos de interaccin entre procesos de un programa concurrente, fueron
estudiados y descritos por Dijkstra (1968), Brinch Hansen (1973) y Hoare (1974). Estos trabajos
constituyeron los principios en que se basaron los sistemas operativos multiproceso de la dcada de los
70 y 80.
Sabas que los sistemas operativos de Microsoft no fueron multiproceso hasta la aparicin de Windows
95 (en 1995)?
MS-DOS era un sistema operativo monousuario y monotarea. Los programadores, no el sistema
operativo, implementaban la alternancia en la ejecucin de las distintas instrucciones de los procesos que
constituan su aplicacin para conseguir interactuar con el usuario. Lo conseguan capturando las
interrupciones hardware del equipo. Adems, MS-DOS, no impeda que unos procesos pudieran
acceder al espacio de trabajo de otros procesos, e incluso al espacio de trabajo del propio sistema
operativo.
Por otro lado, UNIX, que se puede considerar 'antepasado' de los sistemas GNU/Linux, fue diseado
portable, multitarea, multiusuario y en red desde su origen en 1969.

Tema 1. Programacin Multiproceso

4.1.

Pgina 18 de 42

Para qu concurrencia?

CASO PRCTICO.
Por supuesto, la ejecucin de una aplicacin de forma secuencial y aislada en una mquina es lo ms
eficiente para esa aplicacin. Entonces, para qu la concurrencia?
Las principales razones por las que se utiliza una estructura concurrente son:
Optimizar la utilizacin de los recursos. Podremos simultanear las
operaciones de E/S en los procesos. La CPU estar menos tiempo
ociosa. Un equipo informtico es como una cadena de produccin,
obtenemos ms productividad realizando las tareas concurrentemente.

Proporcionar interactividad a los usuarios (y animacin grfica).


Todos nos hemos desesperado esperando que nuestro equipo finalizara
una tarea. Esto se agravara sino existiera el multiprocesamiento, slo
podramos ejecutar procesos por lotes.

Mejorar la disponibilidad. El servidor que no realice tareas de forma


concurrente, no podr atender peticiones de clientes simultneamente.

Conseguir un diseo conceptualmente ms comprensible y


mantenible. El diseo concurrente de un programa nos llevar a
una mayor modularidad y claridad. Se disea una solucin para
cada tarea que tenga que realizar la aplicacin (no todo mezclado en
el mismo algoritmo). Cada proceso se activar cuando sea necesario
realizar cada tarea.

Aumentar la proteccin. Tener cada tarea aislada en un proceso


permitir depurar la seguridad de cada proceso y, poder finalizarlo en caso de mal funcionamiento
sin que suponga la cada del sistema.

Los anteriores pueden parecer los motivos para utilizar concurrencia en sistemas con un solo
procesador. Los actuales avances tecnolgicos hacen necesario tener en cuenta la concurrencia en el
diseo de las aplicaciones para aprovechar su potencial. Los nuevos entornos hardware son:

Microprocesadores con mltiples ncleos que comparten la memoria principal del sistema.
Entornos multiprocesador con memoria compartida. Todos los procesadores utilizan un mismo
espacio de direcciones a memoria, sin tener conciencia de dnde estn instalados fsicamente los
mdulos de memoria.
Entornos distribuidos. Conjunto de equipos heterogneos o no, conectados por red y/o Internet.

Los beneficios que obtendremos al adoptar un modelo de programa concurrente son:


Estructurar un programa como conjunto de procesos concurrentes que
interactan, aporta gran claridad sobre lo que cada proceso debe hacer y
cuando debe hacerlo.
Puede conducir a una reduccin del tiempo de ejecucin. Cuando se trata de
un entorno monoprocesador, permite solapar los tiempos de E/S o de acceso al
disco de unos procesos con los tiempos de ejecucin de CPU de otros procesos.
Cuando el entorno es multiprocesador, la ejecucin de los procesos es realmente simultnea en el
tiempo (paralela), y esto reduce el tiempo de ejecucin del programa.
Permite una mayor flexibilidad de planificacin. Procesos de alta prioridad pueden ser
ejecutados antes de otros procesos menos urgentes.
La concepcin concurrente del software permite un mejor modelado previo del
comportamiento del programa, y en consecuencia un anlisis ms fiable de las diferentes
opciones que requiera su diseo.

Tema 1. Programacin Multiproceso

4.2.

Pgina 19 de 42

Condiciones de competencia.

Acabamos de ver que tenemos que desechar la idea de que nuestra aplicacin se ejecutar de
forma aislada. Y que, de una forma u otra, va a interactuar con otros procesos. Distinguimos los siguientes
tipos bsicos de interaccin entre procesos concurrentes:

Independientes. Slo interfieren en el uso de la CPU.


Cooperantes. Un proceso genera la informacin o proporciona un servicio que otro necesita.
Competidores. Procesos que necesitan usar los mismos recursos de forma exclusiva.

En el segundo y tercer caso, necesitamos componentes que nos permitan establecer acciones
de sincronizacin y comunicacin entre los procesos.
Un proceso entra en condicin de competencia con otro, cuando ambos necesitan el mismo
recurso, ya sea forma exclusiva o no; por lo que ser necesario utilizar mecanismos de sincronizacin y
comunicacin entre ellos.
Un ejemplo sencillo de procesos cooperantes, es un proceso
recolector y un proceso productor. El proceso recolector necesita la informacin
que el otro proceso produce. El proceso recolector, quedar bloqueado mientras
que no haya informacin disponible.
El proceso productor, puede escribir siempre que lo desee (es el
nico que produce ese tipo de informacin). Por supuesto, podemos complicar
esto, con varios procesos recolectores para un slo productor; y si ese productor puede dar informacin a
todos los recolectores de forma simultnea o no; o a cuntos procesos recolectores puede dar servicio de
forma concurrente. Para determinar si los recolectores tendrn que esperar su turno o no. Pero ya
abordaremos las soluciones a estas situaciones ms adelante.
En el caso de procesos competidores, vamos a comenzar viendo unas definiciones:

Cuando un proceso necesita un recurso de forma exclusiva, es porque mientras que lo est
utilizando l, ningn otro puede utilizarlo. Se llama regin de exclusin mutua o regin crtica
al conjunto de instrucciones en las que el proceso utiliza un recurso y que se deben ejecutar
de forma exclusiva con respecto a otros procesos competidores por ese mismo recurso.

Cuando ms de un proceso necesitan el mismo recurso, antes de utilizarlo tienen que pedir su uso,
una vez que lo obtienen, el resto de procesos quedarn bloqueados al pedir ese mismo recurso. Se
dice que un proceso hace un lock (bloqueo) sobre un recurso cuando ha obtenido su uso en
exclusin mutua.

Crees que no es usual que pueda darse una situacin


de interbloqueo? Veamos un ejemplo sencillo: un cruce de
caminos y cuatro coches.
El coche azul necesita las regiones 1 y 3 para
continuar, el amarillo: 2 y 1, el rojo: 4 y 2, y el verde: 3 y 4.
Obviamente, no siempre quedarn bloqueados, pero
se puede dar la situacin en la que ninguno ceda. Entonces, quedarn interbloqueados.

5. Comunicacin entre procesos.


La comunicacin de procesos, qu es?, pasar datos de unos a otros, no? Pero, no estn todos en
memoria? No pueden acceder a la direccin de memoria en la que se encuentre la informacin que
necesitan y ya est?

Tema 1. Programacin Multiproceso

Pgina 20 de 42

Como ya hemos comentado en ms de una ocasin a


lo largo de esta unidad, cada proceso tiene su espacio de
direcciones privado, al que no pueden acceder el resto de
procesos. Esto constituye un mecanismo de seguridad;
imagina qu locura, si tienes un dato en tu programa y
cualquier otro, puede modificarlo de cualquier manera. Tu
programa generara errores, como poco.
Por supuesto, nos damos cuenta de que, si cada
proceso tiene sus datos y otros procesos no pueden acceder a
ellos directamente, cuando otro proceso los necesite, tendr
que existir alguna forma de comunicacin entre ellos.
Comunicacin entre procesos: un proceso da o deja informacin; recibe o recoge informacin.

Por ejemplo dos procesos, compiten por dos recursos distintos, y ambos necesitan ambos recursos
para continuar. Se puede dar la situacin en la que cada uno de los procesos bloquee uno de los
recursos, lo que har que el otro proceso no pueda obtener el recurso que le falta; quedando
bloqueados un proceso por el otro sin poder finalizar. Deadlock o interbloqueo, se produce
cuando los procesos no pueden obtener, nunca, los recursos necesarios para continuar su
tarea. El interbloqueo es una situacin muy peligrosa, ya que puede llevar al sistema a su cada o
cuelgue.

Los lenguajes de programacin y los


sistemas
operativos,
nos
proporcionan
primitivas de sincronizacin que facilitan la
interaccin entre procesos de forma sencilla y
eficiente.
Una primitiva, hace referencia a una
operacin de la cual conocemos sus restricciones
y efectos, pero no su implementacin exacta.
Veremos que usar esas primitivas se traduce en
utilizar objetos y sus mtodos, teniendo muy en
cuenta sus repercusiones reales en el
comportamiento de nuestros procesos.
Clasificaremos las interacciones entre los procesos y el resto del sistema (recursos y otros
procesos), como estas tres:

Sincronizacin: Un proceso puede conocer el punto de ejecucin en el que se encuentra otro en


ese determinado instante.

Exclusin mutua: Mientras que un proceso accede a un recurso, ningn otro proceso accede al
mismo recurso o variable compartida.

Sincronizacin condicional: Slo se accede a un recurso cuando se encuentra en un determinado


estado interno.

Tema 1. Programacin Multiproceso

5.1.

Pgina 21 de 42

Mecanismos bsicos de comunicacin.

Si pensamos en la forma en la que un proceso puede comunicarse


con otro. Se nos ocurrirn estas dos:

Intercambio de mensajes. Tendremos las primitivas enviar


(send) y recibir (receive o wait) informacin.

Recursos (o memoria) compartidos. Las primitivas sern


escribir (write) y leer (read) datos en o de un recurso.

En el caso de comunicar procesos dentro de una misma mquina,


el intercambio de mensajes, se puede realizar de dos formas:

Utilizar un buffer de memoria.

Utilizar un socket.

La diferencia entre ambos, est en que un socket se utiliza para intercambiar informacin entre
procesos en distintas mquinas a travs de la red; y un buffer de memoria, crea un canal de comunicacin
entre dos procesos utilizando la memoria principal del sistema. Actualmente, es ms comn el uso de
sockets que buffers para comunicar procesos. Trataremos en profundidad los sockets en posteriores
unidades. Pero veremos un par de ejemplos muy sencillos de ambos.
En java, utilizaremos sockets y buffers como si utilizramos cualquier otro stream o flujo de
datos. Utilizaremos los mtodos read-write en lugar de send-receive.
Con respecto a las lecturas y escrituras, debemos recordar, que sern bloqueantes. Es decir, un
proceso quedar bloqueado hasta que los datos estn listos para poder ser ledos. Una escritura, bloquear
al proceso que intenta escribir, hasta que el recurso no est preparado para poder escribir.
Ttulo: Solucin en NetBeans de los ejemplos Comunicacin de Procesos con Sockets y tuberas. Incluye los proyectos
SocketEscritor, SocketLector, Escritor y Lector.

PARA SABER MS.


Volvamos a nuestros buffers de memoria. Un buffer de memoria, es creado por el SO en el instante en el que lo
solicita un proceso. El uso de buffers plantea un problema y es, que los buffers suelen crearse dentro del espacio
de memoria de cada proceso, por lo que no son accesibles por el resto. Se puede decir, que no poseen una
direccin o ruta que se pueda comunicar y sea accesible entre los distintos procesos, como sucede con un socket o
con un fichero en disco.
Una solucin intermedia, soportada por la mayora de los SO, es que permiten a los procesos utilizar archivos
mapeados en memoria (memory-mapped file). Al utilizar un fichero mapeado en memoria, abrimos un fichero
de disco, pero indicamos al SO que queremos acceder a la zona de memoria en la que el SO va cargando la
informacin del archivo. El SO utiliza la zona de memoria asignada al archivo como buffer intermedio entre las
operaciones de acceso que estn haciendo los distintos procesos que hayan solicitado el uso de ese archivo y el
fichero fsico en disco. Podemos ver los ficheros mapeados en memoria, como un fichero temporal que existe
solamente en memoria (aunque s tiene su correspondiente ruta de acceso a fichero fsico en disco).
Texto enlace: Ampliar informacin sobre qu son, ventajas e inconvenientes del uso de ficheros mapeados en memoria.
URL: http://es.wikipedia.org/wiki/Archivo_proyectado_en_memoria
Ttulo: Enlace a la web es.wikipedia.org, para ver ampliar informacin sobre el uso, ventajas y desventajas del uso de
ficheros mapeados en memoria.
Texto enlace: En java, podemos utilizar ficheros mapeados en memoria utilizando la clase java.nio.channels.FileChannel.
URL: http://download.oracle.com/javase/6/docs/api/java/nio/channels/FileChannel.html
Ttulo: Enlace a la documentacin oficial de la clase java: FileChannel, en la web oracle.com.

Tema 1. Programacin Multiproceso

5.2.

Pgina 22 de 42

Tipos de comunicacin.

Ya hemos visto que dos procesos pueden comunicarse. Remarquemos algunos conceptos
fundamentales sobre comunicacin.
En cualquier comunicacin, vamos a tener los siguientes elementos:

Mensaje. Informacin que es el objeto de la


comunicacin.
Emisor. Entidad que emite, genera o es origen del
mensaje.
Receptor. Entidad que recibe, recoge o es destinataria
del mensaje.
Canal. Medio por el que viaja o es enviado y recibido el mensaje.

Podemos clasificar el canal de comunicacin segn su capacidad, y los sentidos en los que puede
viajar la informacin, como:

Smplex. La comunicacin se produce en un slo sentido.


El emisor es origen del mensaje y el receptor escucha el
mensaje al final del canal. Ejemplo: reproduccin de una
pelcula en una sala de cine.
Dplex (Full Duplex). Pueden viajar mensajes en ambos
sentidos simultneamente entre emisor y receptor. El
emisor es tambin receptor y el receptor es tambin
emisor. Ejemplo: telefona.
Semidplex (Half Duplex). El mensaje puede viajar en
ambos sentidos, pero no al mismo tiempo. Ejemplo:
comunicacin con walkie-talkies.

Otra clasificacin dependiendo de la sincrona que mantengan el emisor y el receptor durante la


comunicacin, ser:

Sncrona. El emisor queda bloqueado hasta que el receptor recibe el mensaje. Ambos se
sincronizan en el momento de la recepcin del mensaje. queda sincronizada hasta que el receptor recibe el mensaje
Asncrona. El emisor contina con su ejecucin inmediatamente despus de emitir el mensaje, sin
quedar bloqueado.
Invocacin remota. El proceso emisor queda suspendido hasta que recibe la confirmacin de que
el receptor ha recibido correctamente el mensaje, despus emisor y receptor ejecutarn
sncronamente un segmento de cdigo comn.

Dependiendo del comportamiento que tengan los interlocutores que intervienen en la


comunicacin, tendremos comunicacin:

Simtrica. Todos los procesos pueden enviar y recibir informacin.


Asimtrica. Slo un proceso acta de emisor, el resto slo escucharn el o los mensajes.

En nuestro anterior ejemplo bsico de comunicacin con sockets: el proceso SocketEscritor, era el
emisor; el proceso SocketLector, era el receptor. El canal de comunicacin: sockets. En el ejemplo, hemos
utilizado del socket en una sola direccin y sncrona; pero los sockets permiten comunicacin dplex
sncrona (en cada sentido de la comunicacin) y simtrica (ambos procesos pueden escribir en y leer del
socket); tambin existen otros tipos de sockets que nos permitirn establecer comunicaciones asimtricas
asncronas (DatagramSocket).
En el caso del ejemplo de las tuberas, la comunicacin que se establece es simplex sncrona y asimtrica.
Nos damos cuenta, que conocer las caractersticas de la comunicacin que necesitamos establecer
entre procesos, nos permitir seleccionar el canal, herramientas y comportamiento ms convenientes.

1 - 10 - 2014

Tema 1. Programacin Multiproceso

Pgina 23 de 42
por que se sincronizan los procesos ?

6. Sincronizacin entre procesos.


CASO PRCTICO.

porque acceden al mismo recursos , ponerse de acuerdo para escribir y leer

el SO da las instrucciones para sincronizar : con java , metodos , clases , objetos pero usa las primitivas de sincronizacion
del so que usan las librerias

En una aplicacin puede haber muchos procesos idnticos, ejecutndose desde


distintas mquinas, accediendo al mismo recurso: por ejemplo un fichero o una base
de datos. Esto puede provocar resultados inesperados si no se pone especial cuidado
en cmo controlar los accesos a un mismo recurso.
Ya tenemos mucho ms claro, que las situaciones en las que dos o ms procesos tengan que
comunicarse, cooperar o utilizar un mismo recurso; implicar que deba haber cierto sincronismo entre
ellos. O bien, unos tienen que esperar que otros finalicen alguna accin; o, tienen que realizar alguna tarea
al mismo tiempo.
En este captulo, veremos distintas problemticas, primitivas y soluciones de sincronizacin
necesarias para resolverlas. Tambin es cierto, que en el sincronismo entre procesos lo hace posible el
SO, y lo que hacen los lenguajes de programacin de alto nivel es encapsular los mecanismos de
sincronismo que proporciona cada SO en objetos, mtodos y funciones. Los lenguajes de
programacin, proporcionan primitivas de sincronismo entre los distintos hilos que tenga un proceso;
estas primitivas del lenguaje, las veremos en la siguiente unidad.
Comencemos viendo un ejemplo muy sencillo de un problema que se nos plantea de forma ms o
menos comn: inconsistencias en la actualizacin de un valor compartido por varios procesos; as, nos
daremos cuenta de la importancia del uso de mecanismos de sincronizacin.
En programacin concurrente, siempre que accedamos a algn recurso compartido (eso incluye a
los ficheros), deberemos tener en cuenta las condiciones en las que nuestro proceso debe hacer uso de
ese recurso: ser de forma exclusiva o no? Lo que ya definimos anteriormente como condiciones de
competencia.
En el caso de lecturas y escrituras en un fichero, debemos determinar si queremos acceder al
fichero como slo lectura; escritura; o lectura-escritura; y utilizar los objetos que nos permitan establecer
los mecanismos de sincronizacin necesarios para que un proceso pueda bloquear el uso del fichero por
otros procesos cuando l lo est utilizando.
Esto se conoce como el problema de los procesos lectores-escritores. El sistema operativo, nos
ayudar a resolver los problemas que se plantean; ya que:

Si el acceso es de slo lectura. Permitir que todos los procesos lectores, que slo quieren leer
informacin del fichero, puedan acceder simultneamente a l.

En el caso de escritura, o lectura-escritura. El SO nos permitir pedir un tipo de acceso de forma


exclusiva al fichero. Esto significar que el proceso deber esperar a que otros procesos lectores
terminen sus accesos. Y otros procesos (lectores o escritores), esperarn a que ese proceso escritor
haya finalizado su escritura.

Debemos tener en cuenta que, nosotros, nos comunicamos con el SO a travs de los objetos y
mtodos proporcionados por un lenguaje de programacin; y, por lo tanto, tendremos que consultar
cuidadosamente la documentacin de las clases que estamos utilizando para conocer todas las
peculiaridades de su comportamiento.
descargar
En la presentacin 04_AccesosRecursoCompartidoSinSincro.odp, podemos ver cmo
implementamos dos aplicaciones. Una de ellas, lee un valor de un fichero y lo escribe en el mismo fichero
despus de incrementarlo en uno. Otra aplicacin crea un grupo de procesos de la primera aplicacin;
todos esos procesos accedern al mismo fichero para realizar la misma accin. Al final de la ejecucin, al
abrir el fichero que han estado utilizando, el valor que encontremos, ser el que esperamos que debe ser?

Tema 1. Programacin Multiproceso

6.1.

Pgina 24 de 42

Regiones crticas.

CASO PRCTICO.
Por qu no es concurrentemente correcta la aplicacin que hemos visto en el ejemplo del
punto anterior?
Hay partes de nuestros procesos, que no crearn ningn problema aunque sus
instrucciones sean ejecutadas en tiempos de asignacin de CPU distintos e intercalndose con
otras instrucciones de otros procesos. Pero, nos hemos dado cuenta de que, la lectura-incrementoescritura del valor, se debe ejecutar como una unidad y de forma exclusiva, para evitar que se
mezclen las lecturas de unos y otros procesos, que es la principal causa de que no podamos determinar el contenido final del
fichero.
Una situacin que nos plantea un smil, puede ser, hacer la compra en un supermercado. Los procesos, son las
personas que compran. Los recursos compartidos: la charcutera, carnicera, pescadera y caja de salida. Los compradores,
pueden coger los productos que necesiten de las estanteras, sin esperar a nadie; pero, cuando quieran un producto de la
carnicera, deben esperar su turno hasta que puedan ser atendidos por el personal del supermercado; y, ningn otro comprador
se debe colar, ya que las cuentas y los alimentos de uno y otro se mezclaran.

La definicin comn, y que habamos visto anteriormente, de una regin o seccin crtica, es, el
conjunto de instrucciones en las que un proceso accede a un recurso compartido. Para que la
definicin sea correcta, aadiremos que, las instrucciones que forman esa regin crtica, se ejecutarn de
forma indivisible o atmica y de forma exclusiva con respecto a otros procesos que accedan al
mismo recurso compartido al que se est accediendo.
Al identificar y definir nuestras regiones crticas en el cdigo, tendremos en cuenta:

Se protegern con secciones crticas slo aquellas instrucciones que acceden a un recurso
compartido.

Las instrucciones que forman una seccin crtica, sern las mnimas. Incluirn slo las
instrucciones imprescindibles que deban ser ejecutadas de forma atmica.

Se pueden definir tantas secciones crticas como sean necesarias.

Un nico proceso entra en su seccin crtica. El resto de procesos esperan a que ste salga de
su seccin crtica. El resto de procesos esperan, porque encontrarn el recurso bloqueado. El
proceso que est en su seccin crtica, es el que ha bloqueado el recurso.

Al final de cada seccin crtica, el recurso debe ser liberado para que puedan utilizarlo otros
procesos.

Algunos lenguajes de programacin permiten definir bloques de cdigo como secciones crticas.
Estos lenguajes, cuentan con palabras reservadas especficas para la definicin de estas regiones. En Java,
veremos cmo definir este tipo de regiones a nivel de hilo en posteriores unidades.
A nivel de procesos, lo primero, haremos, que nuestro ejemplo de accesos mltiples a un fichero,
sea correcto para su ejecucin en un entorno concurrente. En esta presentacin identificaremos la seccin
o secciones crticas y qu objetos debemos utilizar para conseguir que esas secciones se ejecuten de forma
excluyente.

Tema 1. Programacin Multiproceso

Pgina 25 de 42

En el ejemplo mostrado en la presentacin 05_AccesosRecursoCompartidoConSincro.odp, hemos


visto cmo definir una seccin crtica para proteger las actualizaciones de un fichero. Cualquier
actualizacin de datos en un recurso compartido, necesitar establecer una regin crtica que
implicar como mnimo estas instrucciones:
1. Leer el dato que se quiere actualizar. Pasar el dato a la zona de memoria local al proceso.
2. Realizar el clculo de actualizacin. Modificar el dato en memoria.
3. Escribir el dato actualizado. Llevar el dato modificado de memoria al recurso compartido.
Debemos darnos cuenta de que nos referimos a un recurso compartido de forma genrica, ese recurso
compartido podr ser: memoria principal, fichero, base de datos, etc.
PARA SABER MS.
Adems de bloquear un fichero completo, podemos solicitar al sistema que bloquee slo una
regin del fichero, por lo que varios procesos pueden actualizar al mismo tiempo el fichero
mientras que estn actualizando informacin que se encuentre en zonas distintas y no
solapadas del fichero.
Texto enlace: Ampliar informacin sobre los mtodos lock() de la clase FileChannel.
URL: http://download.oracle.com/javase/6/docs/api/java/nio/channels/FileChannel.html#lock()
Ttulo: Enlace a la web de la documentacin oficial del lenguaje java. Clase FileChannel, mtodos lock().

6.1.1.

Categora de proceso cliente-suministrador.

En este caso, vamos a hacer una introduccin a los procesos que podremos clasificar dentro de la
categora cliente-suministrador.

Cliente. Es un proceso que requiere o solicita informacin o servicios que proporciona otro
proceso.

Suministrador. Probablemente, te suene ms el trmino servidor; pero, no queremos


confundirnos con el concepto de servidor en el que profundizaremos en prximas unidades.
Suministrador, hace referencia a un concepto de proceso ms amplio; un suministrador,
suministra informacin o servicios; ya sea a travs memoria compartida, un fichero, red, o
cualquier otro recurso.

Informacin o servicio es perecedero. La informacin desaparece cuando es consumida por el


cliente; y, el servicio es prestado en el momento en el que cliente y suministrador estn
sincronizados.

Entre un cliente y un suministrador (ojo, empecemos con un proceso de cada), se establece


sincronismo entre ellos, por medio de intercambio de mensajes o a travs de un recurso compartido.
Entre un cliente y un servidor, la comunicacin se establece de acuerdo a un conjunto mensajes a
intercambiar con sus correspondientes reglas de uso; llamado protocolo. Podremos implementar nuestros
propios protocolos, o, protocolos existentes (ftp, http, telnet, smtp, pop3, ); pero an tenemos que ver
algunos conceptos ms antes de implementar protocolos.
Cliente y suministrador, son, los procesos que vimos en nuestros ejemplos de uso bsico de
sockets y comunicacin a travs de tuberas (apartado 4.1. Mecanismos bsicos de comunicacin); y, por
supuesto, se puede extender a los casos en los que tengamos un proceso que lee y otro que escribe en un
recurso compartido.

Tema 1. Programacin Multiproceso

Pgina 26 de 42

Entre procesos cliente y suministrador debemos disponer de mecanismos de sincronizacin que


permitan que:

Un cliente no debe poder leer un dato hasta que no haya sido


completamente suministrado. As nos aseguraremos de que el
dato ledo es correcto y consistente.

Un suministrador ir produciendo su informacin, que en cada


instante, no podr superar un volumen de tamao mximo
establecido; por lo que el suministrador, no debe poder escribir
un dato si se ha alcanzado ese mximo. Esto es as, para no
desbordar al cliente.

Lo ms sencillo, es pensar que el suministrador slo produce un dato que el cliente tiene que
consumir. Qu sincronismo hace falta en esta situacin?
1- El cliente tiene que esperar a que el suministrador haya generado el dato.
2- El suministrador genera el dato y de alguna forma avisa al cliente de que puede consumirlo.
Podemos pensar en dar una solucin a esta situacin con programacin secuencial. Incluyendo
un bucle en el cliente en el que est testeando el valor de una variable que indica que el dato ha sido
producido.
Como podemos ver en este grfico el pseudocdigo del cliente
incluye el bucle del que habamos mencionado. Ese bucle hace que
esta solucin sea poco eficiente, ya que el proceso cliente estara
consumiendo tiempo de CPU sin realizar una tarea productiva; lo
que conocemos como espera activa. Adems, si el proceso
suministrador quedara bloqueado por alguna razn, ello tambin
bloqueara al proceso cliente.
En los prximos apartados, vamos a centrarnos en los mecanismos de programacin concurrente
que nos permiten resolver estos problemas de sincronizacin entre procesos de forma eficiente,
llamados primitivas de programacin concurrente: semforos y monitores; y son estas primitivas las
que utilizaremos para proteger las secciones crticas de nuestros procesos.

6.2.

Semforos.
Veamos una primera solucin eficiente a los problemas de sincronismo, entre
procesos que acceden a un mismo recurso compartido.

Podemos ver varios procesos que quieren acceder al mismo recurso, como coches
que necesitan pasar por un cruce de calles. En nuestros cruces, los semforos nos indican
cundo podemos pasar y cundo no. Nosotros, antes de intentar entrar en el cruce, primero
miramos el color en el que se encuentra el semforo, y si est en verde (abierto), pasamos. Si el color es
rojo (cerrado), quedamos a la espera de que ese mismo semforo nos indique que podemos pasar. Este
mismo funcionamiento es el que van a seguir nuestros semforos en programacin concurrente. Y, son
una solucin eficiente, porque los procesos quedarn bloqueados (y no en espera activa) cuando no
puedan acceder al recurso, y ser el semforo el que vaya desbloquendolos cuando puedan pasar.
Un semforo, es un componente de bajo nivel de abstraccin que permite arbitrar los accesos a
un recurso compartido en un entorno de programacin concurrente.
Al utilizar un semforo, lo veremos como un tipo dato, que podremos instanciar. Ese objeto
semforo podr tomar un determinado conjunto de valores y se podr realizar con l un conjunto
determinado de operaciones. Un semforo, tendr tambin asociada una lista de procesos
suspendidos que se encuentran a la espera de entrar en el mismo.

Tema 1. Programacin Multiproceso

Pgina 27 de 42

Dependiendo del conjunto de datos que pueda tomar un semforo, tendremos:

Semforos binarios. Aquellos que pueden tomar slo valores 0 1. Como nuestras luces verde y
roja.
Semforos generales. Pueden tomar cualquier valor Natural (entero no negativo).

En cualquier caso, los valores que toma un semforo representan:

Valor igual a 0. Indica que el semforo est cerrado.


Valor mayor de 0. El semforo est abierto.

Cualquier semforo permite dos operaciones seguras (la implementacin del semforo garantiza
que la operacin de chequeo del valor del semforo, y posterior actualizacin segn proceda, es siempre
segura respecto a otros accesos concurrentes ):

objSemaforo.wait(): Si el semforo no es nulo (est abierto) decrementa en uno el valor del


semforo. Si el valor del semforo es nulo (est cerrado), el proceso que lo ejecuta se suspende y
se encola en la lista de procesos en espera del semforo.

objSemaforo.signal(): Si hay algn proceso en la lista de procesos del semforo, activa uno de
ellos para que ejecute la sentencia que sigue al wait que lo suspendi. Si no hay procesos en
espera en la lista incrementa en 1 el valor del semforo.

Adems de la operacin segura anterior, con un semforo, tambin podremos realizar una
operacin no segura, que es la inicializacin del valor del semforo. Ese valor indicar cuntos
procesos pueden entrar concurrentemente en l. Esta inicializacin la realizaremos al crear el semforo.
Para utilizar semforos, seguiremos los siguientes pasos:
1) Un proceso padre crear e inicializar el semforo.
2) El proceso padre crear el resto de procesos hijo pasndoles el semforo que ha creado. Esos
procesos hijos acceden al mismo recurso compartido.
3) Cada proceso hijo, har uso de las operaciones seguras wait y signal respetando este esquema:
1. objSemaforo.wait(); Para consultar si puede acceder a la seccin crtica.
2. Seccin crtica; Instrucciones que acceden al recurso protegido por el semforo objSemaforo.
3. objSemaforo.signal(); Indicar que abandona su seccin y otro proceso podr entrar.
- El proceso padre habr creado tantos semforos como tipos secciones crticas distintas se puedan
distinguir en el funcionamiento de los procesos hijos (puede ocurrir, uno por cada recurso
compartido).
La ventaja de utilizar semforos es que son fciles de comprender, proporcionan una gran
capacidad funcional (podemos utilizarlos para resolver cualquier problema de concurrencia). Pero,
su nivel bajo de abstraccin, los hace peligrosos de manejar y, a menudo, son la causa de muchos
errores, como es el interbloqueo. Un simple olvido o cambio de orden conduce a bloqueos; y requieren
que la gestin de un semforo se distribuya por todo el cdigo lo que hace la depuracin de los errores en
su gestin es muy difcil.
En java, encontramos la clase Semaphore dentro del paquete
java.util.concurrent; y su uso real se aplica a los hilos de un mismo
proceso, para arbitrar el acceso de esos hilos de forma concurrente a
una misma regin de la memoria del proceso. Por ello, veremos
ejemplos de su uso en las siguientes unidades de este mdulo.

Tema 1. Programacin Multiproceso

6.3.

Pgina 28 de 42

Monitores.
Los monitores, nos ayudan a resolver las desventajas que encontramos en el uso de
semforos. El problema en el uso de semforos es que, recae sobre el programador o
programadora la tarea de implementar el correcto uso de cada semforo para la proteccin
de cada recurso compartido; y, sigue estando disponible el recurso para utilizarlo sin la
proteccin de un semforo. Los monitores son como guardaespaldas, encargados de la
proteccin de uno o varios recursos especficos; pero encierran esos recursos de forma que
el proceso slo puede acceder a esos recursos a travs de los mtodos que el monitor
expone.

Un monitor, es un componente de alto nivel de abstraccin destinado a gestionar recursos que


van a ser accedidos de forma concurrente.
Los monitores encierran en su interior los recursos o variables compartidas como componentes
privadas y garantizan el acceso a ellas en exclusin mutua (solo puede acceder un proceso
simultneamente a dicho recurso o variable compartida).
La declaracin de un monitor incluye:

Declaracin de las constantes, variables, procedimientos y funciones que son privados del
monitor (solo el monitor tiene visibilidad sobre ellos).
Declaracin de los procedimientos y funciones que el monitor expone (pblicos) y que
constituyen la interfaz a travs de las que los procesos acceden al monitor.
Cuerpo del monitor, constituido por un bloque de cdigo que se ejecuta al ser instanciado o
inicializado el monitor. Su finalidad es inicializar las variables y estructuras internas del
monitor.
Tiene asociada una lista en la que se incluyen los procesos que al tratar de acceder al monitor
son suspendidos.

Los paquetes Java, no proporcionan una implementacin de clase Monitor


(habra que implementar un monitor para cada variable o recurso a sincronizar).
Pero, siempre podemos implementarnos nuestra propia clase monitor,
haciendo uso de semforos para ello.
Pensemos un poco, hemos utilizado objetos que pueden encajar con la
declaracin de un monitor aunque su tipo de dato no fuera monitor?, no?,
seguro? Cuando realizamos una lectura o escritura en fichero, nuestro proceso queda bloqueado hasta
que el sistema ha realizado completamente la operacin. Nosotros inicializamos el uso del fichero
indicando su ruta al crear el objeto, por ejemplo, FileReader; y utilizamos los mtodos expuestos por ese
objeto para realizar las operaciones que deseamos con ese fichero. Sin embargo, el cdigo que realmente
realiza esas operaciones es el implementado en la clase FileReader. Si bien, esos objetos no proporcionan
exclusin mutua en los accesos al recurso; o, por lo menos, no en todos sus mtodos. An as, podemos
decir que utilicemos objetos de tipo monitor al acceder a los recursos del sistema, aunque no tengan
como nombre Monitor.
Las ventajas que proporciona el uso de monitores son:

Uniformidad: El monitor provee una nica capacidad, la exclusin mutua, no existe la confusin
de los semforos (el recurso queda protegido por el monitor para impedir accesos simultneos).
Modularidad: El cdigo que se ejecuta en exclusin mutua est separado, no mezclado con el resto
del programa.
Simplicidad: El programador o programadora no necesita preocuparse de las herramientas para la
exclusin mutua .
Eficiencia de la implementacin: La implementacin subyacente puede limitarse fcilmente a los
semforos.

Tema 1. Programacin Multiproceso

Pgina 29 de 42

Y, la desventaja:

Interaccin de mltiples condiciones de sincronizacin: Cuando el nmero de condiciones crece, y


se hacen complicadas, la complejidad del cdigo crece de manera extraordinaria.

El monitor garantiza el acceso al cdigo interno en rgimen de exclusin mutua.


6.3.1.

Monitores: Lecturas y escrituras bloqueantes en recursos compartidos.

Recordemos, el funcionamiento de los procesos cliente y suministrador podra ser el siguiente:

Utilizan un recurso del sistema a modo de buffer compartido en el que, el


suministrador introduce elementos; y, el cliente los extrae.

Se sincronizarn utilizando una variable compartida que indica el nmero de


elementos que contiene ese buffer compartido, cuyo tamao mximo ser N.

El proceso suministrador, siempre comprueba antes de introducir un elemento, que esa variable
tenga un valor menor que N. Al introducir un elemento incrementa en uno la variable compartida.

El proceso cliente, extraer un elemento del buffer y decrementar el valor de la variable; siempre
que el valor de la variable indique que hay elementos que consumir.

Los mecanismos de sincronismo que nos permiten el anterior funcionamiento entre procesos, son las
lecturas y escrituras bloqueantes en recursos compartidos del sistema (streams). En el caso de java,
disponemos de:

Arquitectura java.io.

Implementacin de clientes: Para sus clases derivadas de Reader como son InputStream,
InputStreamReader, FileReader, ; los mtodos read(buffer) y read(buffer,
desplazamiento, tamao).

Implementacin de suministradores: Con sus anlogos derivados de Writer; los mtodos


write(info) y write(info, desplazamiento, tamao).

Arquitectura java.nio (disponible desde la versin 1.4 de Java). Dentro de java.nio.channels:

Implementacin de clientes: Sus clases FileChannel y SocketChannel; los mtodos


read(buffer) y read(buffer, desplazamiento, tamao).

Implementacin de suministradores: Sus clases FileChannel y SocketChannel; los mtodos


write(info) y write(info, desplazamiento, tamao).

Y recordemos que, como vimos en el apartado 5.1 Regiones crticas; tendremos que hacer uso del
mtodo lock() de FileChannel; para implementar las secciones crticas de forma correcta. Tanto
para suministradores como para clientes, cuando estemos utilizando un fichero como canal de
comunicacin entre ellos.
Podemos ver, cmo conseguir que dos procesos Cliente y Suministrador, se comuniquen
utilizando un fichero, en la presentacin: 06_ClienteSuministrador_fichero.odp
Si nos damos cuenta, hasta ahora slo hemos hablado de un proceso Suministrador y un proceso
cliente. El caso en el que un suministrador tenga que dar servicio a ms de un cliente, aprenderemos a
solucionarlo utilizando hilos o threads, e implementando esquemas de cliente-servidor, en las
prximas unidades. No obstante, debemos tener claro, que el sincronismo cuando hay una informacin
que genera un proceso (o hilo), y que recolecta otro proceso (o hilo) atender a las caractersticas que
hemos descrito en estos apartados.

Tema 1. Programacin Multiproceso

Pgina 30 de 42

PARA SABER MS.


Dependiendo de la aplicacin que vayamos a implementar, podemos encontrarnos en la necesidad de que
el cliente pueda realizar otras operaciones mientras que no haya datos disponibles. Es decir, que las
operaciones de lectura no sean bloqueantes. Un ejemplo claro, es la programacin de un cliente de
streaming de msica o vdeo. Ese cliente es un reproductor on-line que comienza a reproducir los datos
que recibe, sin esperar a que se haya descargado completamente el archivo. Por supuesto, en estas
situaciones tendremos que evaluar las variantes (con respecto a las que hemos visto en esta unidad) en el
sincronismo de los procesos que se comunican.
Para conseguir lecturas no bloqueantes, haremos uso de la arquitectura java.nio, que implementa canales
sobre sockets (SocketChannel). Podremos configurar que las lecturas en un SocketChannel no sean
bloqueantes por medio del mtodo configureBlocking(booleano), cuando booleano sea false.
Las lecturas en un canal creado sobre un fichero (FileSocket) siempre son bloqueantes.
Texto enlace: Ampliar informacin sobre el mtodo configureBlocking(bool) de la clase SocketChannel.
URL:
http://docs.oracle.com/javase/6/docs/api/java/nio/channels/spi/AbstractSelectableChannel.html#configureBlocking(boolean)
Ttulo: Enlace a la web de la documentacin oficial del lenguaje java. Clase SocketChannel, mtodo configureBlocking(bool).

6.4.

Memoria compartida.

Una forma natural de comunicacin entre procesos es la


posibilidad de disponer de zonas de memoria compartidas (variables,
buffers o estructuras). Adems, los mecanismos de sincronizacin en
programacin concurrente que hemos visto: regiones crticas,
semforos y monitores; tienen su razn de ser en la existencia de
recursos compartidos; incluida la memoria compartida.
Cuando se crea un proceso, el sistema operativo le asigna los recursos iniciales que necesita,
siendo el principal recurso: la zona de memoria en la que se guardarn sus instrucciones, datos y pila
de ejecucin. Pero como ya hemos comentado anteriormente, los sistemas operativos modernos,
implementan mecanismos que permiten proteger la zona de memoria de cada proceso siendo sta
privada para cada proceso, de forma que otros no podrn acceder a ella. Con esto, podemos pensar que
no hay posibilidad de tener comunicacin entre procesos por medio de memoria compartida. Pues, no es
as. En la actualidad, la programacin multihilo (que abordaremos en la siguiente unidad y, se refiere, a
tener varios flujos de ejecucin dentro de un mismo proceso, compartiendo entre ellos la memoria
asignada al proceso), nos permitir examinar al mximo esta funcionalidad.
Pensemos ahora en problemas que pueden resultar complicados si los
resolvemos con un slo procesador, por ejemplo: la ordenacin de los
elementos de una matriz. Ordenar una matriz pequea, no supone mucho
problema; pero si la matriz se hace muy muy grande... Si disponemos de
varios procesadores y somos capaces de partir la matriz en trozos (convertir
un problema grande en varios ms pequeos) de forma que cada
procesador se encargue de ordenar cada parte de la matriz. Conseguiremos
resolver el problema en menos tiempo; eso s, teniendo en cuenta la complejidad de dividir el problema
y asignar a cada procesador el conjunto de datos (o zona de memoria) que tiene que manejar y la
tarea o proceso a realizar (y finalizar con la tarea de combinar todos los resultados para obtener la
solucin final). En este caso, tenemos sistemas multiprocesador como los actuales microprocesadores
de varios ncleos, o los supercomputadores formados por mltiples ordenadores completos (e idnticos)
trabajando como un nico sistema. En ambos casos, contaremos con ayuda de sistemas especficos
(sistemas operativos o entornos de programacin), preparados para soportar la carga de
computacin en mltiples ncleos y/o equipos.

Tema 1. Programacin Multiproceso

Pgina 31 de 42

PARA SABER MS.


Aunque en prximos apartados haremos una introduccin a la programacin paralela, es interesante conocer la
existencia de OpenMP en este apartado. Es, una API para la programacin multiproceso de memoria
compartida en mltiples plataformas. Es un estndar disponible en muchas arquitecturas, incluidas las
plataformas de Unix y de Microsoft Windows. Se compone de un conjunto de directivas de compilador, rutinas
de biblioteca, y variables de entorno que influencian el comportamiento en tiempo de ejecucin. OpenMP es un
modelo de programacin portable y escalable que proporciona a los programadores una interfaz simple y flexible
para el desarrollo de aplicaciones paralelas para las plataformas que van desde las computadoras de escritorio
hasta las supercomputadoras. Tambin existe una implementacin de OpenMP en Java.
Texto enlace: Ampliar informacin sobre OpenMP.
URL: http://en.wikipedia.org/wiki/OpenMP
Ttulo: Enlace a wikipedia (en ingls), para ampliar informacin sobre OpenMP.

REFLEXIONA.
Hay problemas complejos cuya solucin se est haciendo ms asequible gracias a la evolucin de la
tecnologa y la programacin concurrente. Piensa, en las distintas variantes que hay que evaluar en
una prediccin meteorolgica: temperatura, humedad, vectores de desplazamiento de las masas de
aire (y a nivel mundial),... Gracias a los supercomputadores, las predicciones meteorolgica son cada
da ms fiables.
Texto enlace: Modelo numrico de prediccin meteorolgica.
URL: http://es.wikipedia.org/wiki/Modelo_num%C3%A9rico_de_predicci%C3%B3n_meteorol%C3%B3gica
Ttulo: Enlace a wikipedia, sobre el interesante modelo numrico de prediccin meteorolgica.

6.5.

Cola de mensajes.
El paso de mensajes es una tcnica empleada en programacin concurrente para aportar
sincronizacin entre procesos y permitir la exclusin mutua, de manera similar a como se
hace con los semforos, monitores, etc. Su principal caracterstica es que no precisa de
memoria compartida.

Los elementos principales que intervienen en el paso de mensajes son el proceso que enva, el
que recibe y el mensaje.
Dependiendo de si el proceso que enva el mensaje espera a que el mensaje sea recibido, se puede
hablar de paso de mensajes sncrono o asncrono:

En el paso de mensajes asncrono, el proceso que enva, no espera a que el mensaje sea
recibido, y contina su ejecucin, siendo posible que vuelva a generar un nuevo mensaje y a
enviarlo antes de que se haya recibido el anterior. Por este motivo se suelen
emplear buzones o colas, en los que se almacenan los mensajes a espera
de que un proceso los reciba. Generalmente empleando este sistema, el
proceso que enva mensajes slo se bloquea o para, cuando finaliza su
ejecucin, o si el buzn est lleno. Para conseguir esto, estableceremos una
serie de reglas de comunicacin (o protocolo) entre emisor y receptor, de
forma que el receptor pueda indicar al emisor qu capacidad restante queda en su cola de
mensajes y si est lleno o no.

En el paso de mensajes sncrono, el proceso que enva el mensaje espera a que un proceso lo
reciba para continuar su ejecucin. Por esto se suele llamar a esta tcnica encuentro, o
rendezvous. Dentro del paso de mensajes sncrono se engloba a la llamada a procedimiento
remoto (RPC), muy popular en las arquitecturas cliente/servidor.

Veremos cmo implementar sincronizacin de procesos con paso de mensajes en las unidades 3, 4 y 5.

Tema 1. Programacin Multiproceso

Pgina 32 de 42

7. Requisitos: seguridad, vivacidad, eficiencia y reusabilidad.


Es importante documentar correctamente el cdigo y tener claras las condiciones de
sincronismo. As, resultar ms fcil disear pruebas para poder depurar los distintos casos que se
puedan presentar y estar seguros de que la aplicacin es correcta y cumple todos los requisitos
necesarios. Antes de instalar la aplicacin tienes que comprobar, principalmente, de que es segura y
eficiente.
Como cualquier aplicacin, los programas concurrentes deben cumplir una serie de requisitos de
calidad. En este apartado, veremos algunos aspectos que nos permitirn desarrollar proyectos
concurrentes con, casi, la completa certeza de que estamos desarrollando software de calidad.
Todo programa concurrente debe satisfacer dos tipos de propiedades:

Propiedades de seguridad ("safety"): estas propiedades son relativas a


que en cada instante de la ejecucin no debe haberse producido algo
que haga entrar al programa en un estado errneo:

Dos procesos no deben entrar simultneamente en una seccin


crtica.

Se respetan las condiciones de sincronismo, como: el consumidor


no debe consumir el dato antes de que el productor los haya
producido; y, el productor no debe producir un dato mientras que el
buffer de comunicacin est lleno.

Propiedades de vivacidad ("liveness") : cada sentencia que se ejecute


conduce en algn modo a un avance constructivo para alcanzar el
objetivo funcional del programa. Son, en general, muy dependientes
de la poltica de planificacin que se utilice. Ejemplos de propiedades de vivacidad son:

No deben producirse bloqueos activos (livelock). Conjuntos de procesos que ejecutan de


forma continuada sentencias que no conducen a un progreso constructivo.

Aplazamiento indefinido (starvation): consiste en el estado de aplazamiento indefinido al


que puede llegar un programa aunque potencialmente pueda avanzar de forma constructiva.
Esto puede suceder, como consecuencia de que no se le asigna tiempo de procesador en la
poltica de planificacin; o, porque en las condiciones de sincronizacin hemos establecido
criterios de prioridad que perjudican siempre al mismo proceso.

Interbloqueo (deadlock): se produce cuando los procesos no pueden obtener, nunca, los
recursos necesarios para finalizar su tarea. Vimos un ejemplo de esta situacin en el apartado
4.2 Condiciones de competencia.

Es evidentemente, que tambin nos preocuparemos por disear nuestras aplicaciones para que sean
eficientes:

No utilizarn ms recursos de los necesarios.


Buscaremos la rigurosidad en su implementacin: toda la funcionalidad esperada de forma
correcta y concreta.

Y, en cuanto a la reusabilidad, debemos tenerlo ya, muy bien aprendido:

Implementar el cdigo de forma modular: definiendo clases, mtodos, funciones, ...


Documentar correctamente el cdigo y el proyecto.

Para conseguir todos lo anterior contaremos con los patrones de diseo; y pondremos especial cuidado
en documentar y depurar convenientemente.

Tema 1. Programacin Multiproceso

7.1.

Pgina 33 de 42

Arquitecturas y patrones de diseo.

La Arquitectura del Software, tambin denominada arquitectura lgica,


es el diseo de ms alto nivel de la estructura de un sistema. Consiste en un
conjunto de patrones y abstracciones coherentes con base a las cuales se
pueden resolver los problemas. A semejanza de los planos de un edificio o
construccin, estas indican la estructura, funcionamiento e interaccin entre
las partes del software.
La arquitectura de software, tiene que ver con el diseo y la
implementacin de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto nmero de
elementos arquitectnicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos
de desempeo de un sistema, as como requerimientos no funcionales, como la confiabilidad,
escalabilidad, portabilidad, y disponibilidad; mantenibilidad, auditabilidad, flexibilidad e
interaccin.
Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de
informacin. Lo habitual es adoptar una arquitectura conocida en funcin de sus ventajas e
inconvenientes para cada caso en concreto. As, las arquitecturas ms universales son:

Monoltica. El software se estructura en grupos funcionales muy acoplados.

Cliente-servidor. El software reparte su carga de cmputo en dos partes independientes: consumir


un servicio y proporcionar un servicio.

Arquitectura de tres niveles. Especializacin de la arquitectura cliente-servidor donde la carga se


divide en capas con un reparto claro de funciones: una capa para la presentacin (interfaz de
usuario), otra para el clculo (donde se encuentra modelado el negocio) y otra para el
almacenamiento (persistencia). Una capa solamente tiene relacin con la siguiente.

Otras arquitecturas menos conocidas son:

En pipeline. Consiste en modelar un proceso comprendido por varias fases secuenciales, siendo
la entrada de cada una la salida de la anterior.

Entre pares. Similar a la arquitectura cliente-servidor, salvo porque podemos decir que cada
elemento es igual a otro (acta simultneamente como cliente y como servidor).

En pizarra. Consta de mltiples elementos funcionales (llamados agentes) y un instrumento de


control o pizarra. Los agentes estarn especializados en una tarea concreta o elemental. El
comportamiento bsico de cualquier agente, es: examinar la pizarra, realizar su tarea y escribir sus
conclusiones en la misma pizarra. De esta manera, otro agente puede trabajar sobre los resultados
generados por otro.

Orientada a servicios (Service Oriented Architecture - SOA) Se disean servicios de aplicacin


basados en una definicin formal independiente de la plataforma subyacente y del lenguaje de
programacin, con una interfaz estndar; as, un servicio C# podr ser usado por una aplicacin
Java.

Dirigida por eventos. Centrada en la produccin, deteccin, consumo de, y reaccin a eventos.

Tema 1. Programacin Multiproceso

Pgina 34 de 42

Los patrones de diseo, se definen como soluciones de diseo que son vlidas en distintos
contextos y que han sido aplicadas con xito en otras ocasiones:

Ayudan a arrancar en el diseo de un programa complejo.

Dan una descomposicin de objetos inicial bien pensada.


Pensados para que el programa sea escalable y fcil de
mantener.
Otra gente los ha usado y les ha ido bien.

Ayudan a reutilizar tcnicas.

Mucha gente los conoce y ya sabe como aplicarlos.


Estn en un alto nivel de abstraccin.
El diseo se puede aplicar a diferentes situaciones.

Existen dos modelo bsicos de programas concurrentes:

Un programa resulta de la actividad de objetos activos que interaccionan entre si directamente o


a travs de recursos y servicios pasivos.

Un programa resulta de la ejecucin concurrente de tareas. Cada tarea es una unidad de trabajo
abstracta y discreta que idealmente puede realizarse con independencia de las otras tareas.

No es obligatorio utilizar patrones, solo es aconsejable en el caso de tener el mismo problema o


similar que soluciona el patrn, siempre teniendo en cuenta que en un caso particular puede no ser
aplicable.
Como podemos ver en la siguiente web, lo normal es que encontremos la definicin de los
patrones de diseo en UML (Unified Modeling Language Lenguaje Unificado de Modelado).
Texto enlace: Enlace a la web SourceMaking (en ingls), con ejemplos de patrones de diseo, implementados.
URL: http://sourcemaking.com/design_patterns
Ttulo: Web con algunos patrones de diseo de ejemplo (en ingls, pero fciles de comprender), incluyen ejemplos de
implementacin en varios lenguajes de programacin (tambin en java).

Aunque un diagrama UML es muy fcil de entender, en el siguiente enlace, encontrars un tutorial
sencillito.
Texto enlace: Enlace a la web DocIRS, a su tutorial sobre UML.
URL: http://www.docirs.cl/uml.htm
Ttulo: Enlace a un tutorial de UML con muchos ejemplos.

PARA SABER MS.


En 1990 se public un libro que recopilaba 23 patrones de diseo comunes. Este libro marc el punto
de inicio en el que los patrones de diseo tuvieron gran xito en el mundo de la informtica. En la
actualidad, seguimos haciendo uso de esos 23 patrones y algunos adicionales, sobre todo relacionados
con el diseo de interfaces web.
Texto enlace: Enlace a la versin on-line del libro Design Patterns Book.
URL: http://c2.com/cgi/wiki?DesignPatternsBook
Ttulo: Enlace a la versin on-line del libro Design Patterns Book de GoF (nombre por el que se conoce a sus cuatro
autores).

Tema 1. Programacin Multiproceso

Pgina 35 de 42

PARA SABER MS.


La arquitectura SOA es de gran importancia en el desarrollo de aplicaciones en el mundo empresarial,
porque disear siguiendo esta arquitectura, permite una gran integracin e interoperabilidad entre
servicios y aplicaciones.
Texto enlace: Enlace al artculo por qu SOA?
URL: http://blogs.tecsisa.com/articulos-tecnicos/por-que-soa/
Ttulo: Enlace al blog tecsisa, al post por qu SOA?
Texto enlace: Enlace al documento pdf del modelo de referencia SOA.
URL: http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
Ttulo: Enlace a la web OASIS, al documento con el modelo de referencia de SOA, en ingls.

7.2.

Documentacin

Para la documentacin de nuestras aplicaciones tendremos en cuenta:


Hay que aadir explicaciones a todo lo que no es evidente. Pero, no hay que repetir lo que se hace, sino explicar por qu se
hace.

Documentando nuestro cdigo responderemos a estas preguntas:

De qu se encarga una clase? Un paquete?

Qu hace un mtodo? Cul es el uso esperado de un mtodo?

Para qu se usa una variable? Cul es el uso esperado de una variable?

Qu algoritmo estamos usando? De dnde lo hemos sacado?

Qu limitaciones tiene el algoritmo? ... la implementacin?

Qu se debera mejorar ... si hubiera tiempo?

En la siguiente tabla tenemos un resumen de los distintos tipos de comentarios en Java:


javadoc

una lnea

tipo C

Sintxis Comienzan con "/**", se pueden prolongar Comienzan con


"//" y Comienzan con "/*", se pueden
a lo largo de varias lneas (que terminan con la lnea.
prolongar a lo largo de varias
probablemente comiencen con el carcter
lneas
(que
probablemente
"*") y terminan con los caracteres "*/".
comiencen con el carcter "*") y
terminan con los caracteres "*/".
Cuenta con etiquetas especficas tipo:
@author, @param, @return,...
Propsito Generar documentacin externa.

Uso

Obligado:
Al principio de cada clase.
Al principio de cada mtodo.
Antes de cada variable de clase.

Documentar cdigo que no Eliminar cdigo.


necesitamos que aparezca
en
la
documentacin
externa.
Al principio de fragmento Ocurre a menudo que cdigo

de cdigo no evidente.

obsoleto no queremos que


desaparezca, sino mantenerlo
A lo largo de los bucles.
"por si acaso". Para que no se
Siempre que hagamos algo ejecute, se comenta.
raro o que el cdigo no sea
evidente.

Tema 1. Programacin Multiproceso

Pgina 36 de 42

DEBES CONOCER.
Debes consultar los siguientes enlaces para completar tus conocimientos en la generacin de
documentacin con javadoc.
Texto enlace. Documentacin oficial sobre Javadoc (ingls).
URL: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
Ttulo: Enlace a la pgina de oracle, a la seccin dedicada a javadoc.

Texto enlace. Vdeo tutorial, sobre cmo colocar los comentarios para generar documentacin con
Javadoc.
URL: http://www.youtube.com/watch?v=e34isRNJ_q4
Ttulo: Muestra

como se debern de colocar los comentarios en el cdigo fuente de las clases para poder
generar una documentacin "automtica" de todo el proyecto.
Resumen vdeo: JavaDoc es una utilidad que nos permite crear documentacin con aspecto profesional
sobre el cdigo que estamos escribiendo. La documentacin se genera a partir de los comentarios que
incluimos en los ficheros de las clases de nuestros proyectos. Los comentarios permitirn generar de
forma casi automtica la documentacin. Los comentarios que utilizar JavaDoc, comenzarn con los
smbolos /**, en lugar de / y un slo *. Vemos cmo se incluyen comentarios para JavaDoc al inicio de
cada clase del proyecto y antes de cada mtodo y propiedad. Adems, los comentarios de JavaDoc,
incluyen palabras reservadas que permiten indicar el autor, que es @author; la versin, @version. Las
anteriores se utilizarn en los comentarios al inicio de la clase. En los comentarios de un mtodo,
comenzaremos dando una descripcin del mtodo, y despus utilizaremos la etiqueta @params para
indicar el nombre y la descripcin de cada parmetro. En el caso de un mtodo devuelva un valor,
utilizaremos la etiqueta @return, para describir el valor que devuelve. Los comentarios que incluyamos
en el mtodo main, nos permitirn indicar qu hace todo el programa. Tambin podemos utilizar @link
para incluir en la documentacin un enlace a la documentacin de otra clase; para ello, slo tendremos
que incluir entre llaves, la etiqueta @link e indicar el nombre de la clase cuya documentacin queramos
enlazar.
Para generar la documentacin, sobre el proyecto haremos clic con el botn secundario del ratn y
seleccionaremos 'Generar JavaDoc', lo que har que haga que se compilen los comentarios y se abra el
navegador web para mostrarnos el contenido de la documentacin generada en formato html. Podemos
ver que la documentacin, estructura e incluye toda la informacin sobre la clase, sus propiedades y
mtodos.
Fin resmen vdeo.
Texto enlace. Ejemplo escueto y conciso de comentarios con Javadoc.
URL: http://nomeaclaro.wordpress.com/2009/09/16/documentar-el-codigo-java-con-javadoc/
Ttulo: Enlace a un breve artculo en el blog NoMeAclaro, que incluye un ejemplo de comentarios para documentacin con
javadoc.

DESTACADO
Adems de lo anterior, al documentar nuestras aplicaciones concurrentes destacaremos:
Las condiciones de sincronismo que se hayan implementado en la clase o mtodo (en la documentacin javadoc).
Destacaremos las regiones crticas que hayamos identificado y el recurso que compartido a proteger.

Tema 1. Programacin Multiproceso

7.3.

Pgina 37 de 42

Dificultades en la depuracin.

Cuando estamos programando aplicaciones que incluyen mecanismos de


sincronizacin y acceden a recursos de forma concurrente junto con otras
aplicaciones. A la hora de depurarlas, nos enfrentaremos a:

Los mismos problemas de depuracin de una aplicacin secuencial.


Adems de nuevos errores de temporizacin y sincronizacin propios de
la programacin concurrente.

Los programas secuenciales presentan una lnea simple de control de flujo. Las operaciones de este tipo
de programas estn estrictamente ordenados como una secuencia temporal lineal.

El comportamiento del programa es solo funcin de la naturaleza de las operaciones individuales


que constituye el programa y del orden en que se ejecutan.
En los programas secuenciales, el tiempo que tarda cada operacin en ejecutarse no tiene
consecuencias sobre el resultado.
Para validar un programa secuencial se necesitaremos comprobar:

La correcta respuesta a cada sentencia.

El correcto orden de ejecucin de las sentencias.

Para validar un programa concurrente se requiere comprobar los mismos aspectos que en los programas
secuenciales, adems de los siguientes nuevos aspectos:

Las sentencias se pueden validar individualmente solo si no estn involucradas en el uso de


recursos compartidos.

Cuando existen recursos compartidos, los efectos de interferencia entre las sentencias
concurrentes pueden ser muy variados y la validacin es muy difcil. Comprobaremos la
correccin en la definicin de las regiones crticas y que se cumple la exclusin mutua.

Al comprobar la correcta implementacin del sincronismo entre aplicaciones; que es forzar la


ejecucin secuencial de tareas de distintos procesos, introduciendo sentencias explcitas de
sincronizacin. Tendremos en cuenta que el tiempo no influye sobre el resultado.

El problema es que las herramientas de depuracin no nos proporcionan toda la funcionalidad que
quisiramos para poder depurar nuestros programas concurrentes.
Con qu herramientas contamos para depurar programas concurrentes?

El depurador del IDE NetBeans. En la Unidad 2, veremos que el depurador


de NetBeans, s est preparado para la depuracin concurrente de hilos dentro
de un mismo proceso. En esta unidad estamos tratando procesos
independientes.

Hacer volcados de actividad en un fichero de log o en pantalla de salida (nos


permitir hacernos una idea de lo que ha estado pasando durante las pruebas de depuracin).

Herramientas de depuracin especficas: TotalView (SW comercial), StreamIt Debugger Tool


(plugin para eclipse), ...

Una de las nuevas situaciones a las que nos enfrentamos es que a veces, los errores que parecen
estar sucediendo, pueden desaparecer cuando introducimos cdigo para tratar de identificar el
problema.
Nos damos cuenta de la complejidad que entraa depurar el comportamiento de aplicaciones
concurrentes, es por ello, que al disearlas, tendremos en cuenta los patrones de diseo, que ya estn
diseados resolviendo errores comunes de la concurrencia. Podemos verlos como 'recetas', que nos
permiten resolver los problemas 'tipo' que se presentan en determinadas condiciones de sincronismo
y/o en los accesos concurrentes a un recurso.

Tema 1. Programacin Multiproceso

Pgina 38 de 42

PARA SABER MS.


En la depuracin de programas, es inevitable realizar pruebas. Las pruebas que realicemos
debern estar bien diseadas.
Texto enlace: Introduccin a la prueba de programas.
URL: http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm
Ttulo: Enlace a la web de la Universidad Politcnica de Madrid, introduccin a la prueba de programas, con
ejemplos.
Texto enlace: Automatizar pruebas de clases java con JUnit.
URL: http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/aceptacion.htm
Ttulo: Enlace a la web de la Universidad Politcnica de Madrid, introduccin a la automatizacin de pruebas
de clases java con JUnit.

8. Programacin paralela y distribuida.


El trmino clster (del ingls clster) se aplica a los conjuntos o conglomerados de computadoras
construidos mediante la utilizacin de hardwares comunes y que se comportan como si fuesen una nica
computadora.
Dos procesos se ejecutan de forma paralela, si las instrucciones de ambos se estn ejecutando
realmente de forma simultnea. Esto sucede en la actualidad en sistemas que poseen ms de un ncleo
de procesamiento.
La programacin paralela y distribuida consideran los aspectos conceptuales y fsicos de la
computacin paralela; siempre con el objetivo de mejorar las prestaciones aprovechado la ejecucin
simultnea de tareas.
Tanto en la programacin paralela como distribuida, existe ejecucin simultnea de tareas que
resuelven un problema comn. La diferencia entre ambas es:

La programacin paralela se centra en microprocesadores


multincleo (en nuestros PC y servidores); o ,sobre los
llamados supercomputadores, fabricados con arquitecturas
especficas, compuestos por gran cantidad de equipos idnticos
interconectados entre s, y que cuentan son sistemas operativos
propios.

La programacin distribuida, en sistemas formados por un conjunto de


ordenadores heterogneos interconectados entre s, por redes de
comunicaciones de propsito general: redes de rea local, metropolitana;
incluso, a travs de Internet. Su gestin se realiza utilizando componentes,
protocolos estndar y sistemas operativos de red.

En la computacin paralela y distribuida:

Cada procesador tiene asignada la tarea de resolver una porcin del problema.

En programacin paralela, los procesos pueden intercambiar datos, a travs de direcciones de


memoria compartidas o mediante una red de interconexin propia.

En programacin distribuida, el intercambio de datos y la sincronizacin se realizar mediante


intercambio de mensajes.

El sistema se presenta como una unidad ocultando la realidad de las partes que lo forman.

Tema 1. Programacin Multiproceso

Pgina 39 de 42

PARA SABER MS.


Cada 6 meses se publica un ranking con 500 supercomputadores ms potentes del mundo. En
noviembre de 2011 el supercomputador ms potente se encuentra en Japn y posee ms de
700.000 ncleos de procesamiento. Curiosamente, en junio de 2005, el computador
MareNostrum que se encuentra en Barcelona ocup el puesto 5 del Top500, con sus nada
despreciables 4800 ncleos.
Texto enlace: Listas de rankings del Top500.
URL: http://www.top500.org/lists
Ttulo: Enlace a la web Top500, a su seccin con la recopilacin de los rankings de sus distintas ediciones,
publicadas desde junio de 2003.

8.1.

Conceptos bsicos.

Comencemos revisando algunas clasificaciones de sistemas distribuidos y paralelos:

En funcin de los conjuntos de instrucciones y datos (conocida como la taxonoma de Flynn):

Las cuatro clasificaciones definidas por Flynn se basan en el nmero de instrucciones concurrentes
(control) y en los flujos de datos disponibles en la arquitectura:

La arquitectura secuencial la denominaramos SISD (single instruction


single data) una instruccin, un dato : computador secuencial que no
explota el paralelismo en las instrucciones ni en flujos de datos. Ejemplos
de arquitecturas SISD son las mquinas con uni-procesador o
monoprocesador tradicionales como el PC o los antiguos mainframe.

Las diferentes arquitecturas paralelas (o distribuidas) en diferentes


grupos:

SIMD (single instruction multiple data): Una instruccin, mltiples datos, un computador
que explota varios flujos de datos dentro de un nico flujo de instrucciones para realizar
operaciones que pueden ser paralelizadas de manera natural. Por ejemplo, un procesador
vectorial (un procesador vectorial es un diseo de CPU capaz de ejecutar operaciones
matemticas sobre mltiples datos de forma simultnea, en contraste con los procesadores
escalares, capaces de manejar slo un dato cada vez.)

MISD (multiple instruction single data): Mltiples instrucciones, un dato, poco comn
debido al hecho de que la efectividad de los mltiples flujos de instrucciones suele precisar
de mltiples flujos de datos. Sin embargo, este tipo se usa en situaciones de paralelismo
redundante, como por ejemplo en navegacin area, donde se necesitan varios sistemas de
respaldo en caso de que uno falle. Tambin se han propuesto algunas arquitecturas tericas
que hacen uso de MISD, pero ninguna lleg a producirse en masa.

MIMD (multiple instruction multiple data), con algunas variaciones como la SPMD
(single program multiple data). Mltiples instrucciones, mltiples datos varios
procesadores autnomos que ejecutan simultneamente instrucciones diferentes sobre
datos diferentes. Los sistemas distribuidos suelen clasificarse como arquitecturas MIMD;
bien sea explotando un nico espacio compartido de memoria, o uno distribuido.

Tema 1. Programacin Multiproceso

Pgina 40 de 42

Por comunicacin y control:

Sistemas de multiprocesamiento simtrico (SMP). Son MIMD con memoria compartida.


Los procesadores se comunican a travs de esta memoria compartida; este es el caso de los
microprocesadores de mltiples ncleos de nuestros PCs.
Sistemas MIMD con memoria distribuida. La memoria est distribuida entre los
procesadores (o nodos) del sistema, cada uno con su propia memoria local, en la que poseen su
propio programa y los datos asociados. Una red de interconexin conecta los procesadores (y
sus memorias locales), mediante enlaces (links) de comunicacin, usados para el intercambio
de mensajes entre los procesadores. Los procesadores intercambian datos entre sus memorias
cuando se pide el valor de variables remotas. Tipos especficos de estos sistemas son:
Clusters. Consisten en una coleccin de ordenadores (no necesariamente homogneos)
conectados por red para trabajar concurrentemente en tareas del mismo programa. Aunque
la interconexin puede no ser dedicada.
Grid. Es un cluster cuya interconexin se realiza a travs de internet.

Veamos una introduccin a algunos conceptos bsicos que debemos conocer para desarrollar en
sistemas distribuidos:

Distribucin: construccin de una aplicacin por partes, a cada parte se le


asigna un conjunto de responsabilidades dentro del sistema.
Nudo de la red: uno o varios equipos que se comportan como una unidad de
asignacin integrada en el sistema distribuido.
Un objeto distribuido es un mdulo de cdigo con plena autonoma que se
puede instanciar en cualquier nudo de la red y a cuyos servicios pueden acceder clientes ubicados
en cualquier otro nudo.
Componente: elemento de software que encapsula una serie de funcionalidades. Un
componente, es una unidad independiente, que puede ser utilizado en conjunto con otros
componentes para formar un sistema ms complejo (concebido por ser reutilizable). Tiene
especificado: los servicios que ofrece; los requerimientos que necesarios para poder ser instalado
en un nudo; las posibilidades de configuracin que ofrece; y, no est ligado a ninguna
aplicacin, que se puede instanciar en cualquier nudo y ser gestionado por herramientas
automticas. Sus caractersticas:
Alta cohesin: todos los elementos de un componente estn estrechamente relacionados.
Bajo acoplamiento: nivel de independencia que un componente respecto a otros.
Transacciones: Conjunto de actividades que se ejecutan en diferentes nudos de una
plataforma distribuida para ejecutar una tarea de negocio. Una transaccin finaliza cuando
todas las parte implicadas clientes y mltiples servidores confirman que sus correspondientes
actividades han concluido con xito. Propiedades ACID de una transaccin:
Atomicidad: Una transaccin es una unidad indivisible de trabajo, todas las actividades que
comprende deben ser ejecutadas con xito.
Congruencia: Despus de que una transaccin ha sido ejecutada, la transaccin debe dejar el
sistema en estado correcto. Si la transaccin no puede realizarse con xito, debe restaurar el
sistema al estado original previo al inicio de la transaccin.
Aislamiento: La transacciones que se ejecutan de forma concurrente no deben tener
interferencias entre ellas. La transaccin debe sincronizar el acceso a todos los recursos
compartidos y garantizar que las actualizaciones concurrentes sean compatibles entre si.
Durabilidad: Los efectos de una transaccin son permanentes una vez que la transaccin ha
finalizado con xito.
Gestor de transacciones. Controla y supervisa la ejecucin de transacciones, asegurando sus
propiedades ACID.

Tema 1. Programacin Multiproceso

8.2.

Pgina 41 de 42

Tipos de paralelismo.

Las mejoras arquitectnicas que han sufrido los computadores se han basado en la obtencin de
rendimiento explotando los diferentes niveles de paralelismo.
En un sistema podemos encontrar los siguientes niveles de paralelismo:

A nivel de bit. Conseguido incrementando el tamao de la palabra del


microprocesador. Realizar operaciones sobre mayor nmero de bits. Esto es, el
paso de palabras de 8 bits, a 16, a 32 y en los microprocesadores actuales de 64
bits.
A nivel de instrucciones. Conseguida introduciendo pipeline (la segmentacin
consiste en descomponer la ejecucin de cada instruccin en varias etapas para
poder empezar a procesar una instruccin diferente en cada una de ellas y trabajar
con varias a la vez) en la ejecucin de instrucciones mquina en el diseo de los
microprocesadores.
A nivel de bucle. Consiste en dividir las interaciones de un bucle en partes que se pueden realizar
de manera complementaria. Por ejemplo, un bucle de 0 a 100; puede ser equivalente a dos bucles,
uno de 0 a 49 y otro de 50 a 100.
A nivel de procedimientos. Identificando qu fragmentos de cdigo dentro de un programa
pueden ejecutarse de manera simultnea sin interferir la tarea de una en la otra.
A nivel de tareas dentro de un programa. Tareas que cooperan para la solucin del programa
general (utilizado en sistemas distribuidos y paralelos).
A nivel de aplicacin dentro de un ordenador. Se refiere a los conceptos que vimos al principio
de la unidad, propios de la gestin de procesos por parte del sistema operativo multitarea:
planificador de procesos, Round-Robin, quamtum, etc.

En sistemas distribuidos hablaremos del tamao de grano o granularidad, que es una medida de la
cantidad de computacin de un proceso software. Y se considera como el segmento de cdigo escogido
para su procesamiento paralelo.

Paralelismo de Grano Fino: No requiere tener mucho conocimiento del cdigo, la


paralelizacin se obtiene de forma casi automtica. Permite obtener buenos resultados en
eficiencia en poco tiempo. Por ejemplo: la descomposicin de bucles.

Paralelismo de Grano Grueso: Es una paralelizacin de alto nivel, que engloba al grano fino.
Requiere mayor conocimiento del cdigo, puesto que se paraleliza mayor cantidad de l.
Consigue mejores rendimientos, que la paralelizacin fina, ya que intenta evitar los overhead
(exceso de recursos asignados y utilizados) que se suelen producir cuando se divide el problema
en secciones muy pequeas. Un ejemplo de paralelismo grueso lo obtenemos descomponiendo el problema en
dominios (dividiendo conjunto de datos a procesar, acompaando a estos, las acciones que deban realizarse sobre
ellos).

PARA SABER MS.


En programacin paralela, adems de utilizar CPUs, se utilizan GPU (las unidades de procesamiento de las
tarjetas grficas). Las GPU poseen una mayor potencia de cmputo al ser procesadores especficamente
diseados para resolver tareas intensivas de cmputo en tiempo real de direccionamiento de grficos en 3D de alta
resolucin. En general, tienen muy buen comportamiento en algoritmos de ordenacin rpida de grandes listas de
datos, y transformaciones bidimensionales.
El proyecto de arquitectura de computacin paralela con GPUs CUDA, de NVidia, puede programarse en
multitud de lenguajes de programacin.
Por ejemplo, las simulaciones de dinmica molecular obtienen mejores resultados en sistemas CUDA.
Texto enlace: Proyecto CUDA de NVidia.
URL: http://www.nvidia.com/object/cuda_home_new.html
Ttulo: Enlace a NVidia, el proyecto CUDA (en ingls), la programacin paralela, hecha fcil.

Tema 1. Programacin Multiproceso

8.3.

Pgina 42 de 42

Modelos de infraestructura para programacin distribuida.

Las aplicaciones distribuidas requieren que componentes que se ejecutan en diferentes


procesadores se comuniquen entre s. Los modelos de infraestructura que permiten la
implementacin de esos componentes, son:

Uso de Sockets: Facilitan la generacin dinmica de canales de comunicacin. Es


actualmente la base de la comunicacin. Pero al ser de muy bajo nivel de abstraccin, no son
adecuados a nivel de aplicacin.

Remote Procedure Call (RPC): Abstrae la comunicacin a nivel de invocacin de


procedimientos. Es adecuada para programacin estructurada basada en libreras.

Invocacin remota de objetos: Abstrae la comunicacin a la invocacin de mtodos de objetos


que se encuentran distribuidos por el sistema distribuido. Los objetos se localizan por su
identidad. Es adecuada para aplicaciones basadas en el paradigma OO.
RMI (Remote Method Invocation) es la solucin Java para la comunicacin de objetos Java
distribuidos. Presenta un inconveniente, y es el paso de parmetros por valor implica tiempo para
hacer la serializacin, enviar los objetos serializados a travs de la red y luego volver a
recomponer los objetos en el destino.

CORBA (Common Object Request Brocker Architecture) . Para facilitar el diseo de aplicaciones
basadas en el paradigma Cliente/Servidor. Define servidores estandarizados a travs de un modelo
de referencia, los patrones de interaccin entre clientes y servidores y las especificaciones de las
APIs.

MPI ("Message Passing Interface", Interfaz de Paso de Mensajes) es un estndar que define la
sintaxis y la semntica de las funciones contenidas en una biblioteca de paso de mensajes diseada
para ser usada en programas que exploten la existencia de mltiples procesadores.
La Interfaz de Paso de Mensajes es un protocolo de comunicacin entre computadoras. Es el estndar para la
comunicacin entre los nodos que ejecutan un programa en un sistema de memoria distribuida. Las llamadas de MPI
se dividen en cuatro clases:
Llamadas utilizadas para inicializar, administrar y finalizar comunicaciones.
Llamadas utilizadas para transferir datos entre un par de procesos.
Llamadas para transferir datos entre varios procesos.
Llamadas utilizadas para crear tipos de datos definidos por el usuario.

Mquina paralela virtual. Paquetes software que permite ver el conjunto de nodos disponibles
como una mquina virtual paralela ; ofreciendo una opcin prctica, econmica y popular hoy en
da para aproximarse al cmputo paralelo . La Mquina Virtual Paralela es una biblioteca para el cmputo
paralelo en un sistema distribuido de computadoras. Est diseado para permitir que una red de computadoras
heterognea comparta sus recursos de cmputo (como el procesador y la memoria RAM) con el fin de aprovechar
esto para disminuir el tiempo de ejecucin de un programa al distribuir la carga de trabajo en varias computadoras.

PARA SABER MS.


Existen gran cantidad de proyectos computacin distribuida. En el siguiente enlace, puedes ver un
listado de ellos. Por curiosidad, dos se estn desarrollando en la Univerdidad Complutense de Madrid.
Uno de ellos es una red neuronal que simula el comportamiento de la gran y compleja red de clulas
neuronales autmatas; otro proyecto, utiliza modelos matemticos de una red social, para estudiar la
evolucin ideolgica de un grupo de personas a travs del tiempo.
Texto enlace: Lista de proyectos de computacin distribuida.
URL: http://en.wikipedia.org/wiki/List_of_distributed_computing_projects
Ttulo: Enlace a wikipedia, lista de proyectos de computacin distribuida (en ingls).

You might also like