Professional Documents
Culture Documents
Programacin Multiproceso
Pgina 1 de 42
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
Pgina 2 de 42
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:
1.1.
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.
Pgina 3 de 42
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.
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:
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,
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.
3.1.
Pgina 6 de 42
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.
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.
3.3.
Pgina 8 de 42
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).
Identificador del proceso o PID. Es un nmero nico para cada proceso, como un DNI de
proceso.
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.
3.3.1.
Pgina 9 de 42
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
orden de prioridad
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
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.
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?
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.
Pgina 11 de 42
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
Pgina 12 de 42
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:
Pgina 13 de 42
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).
3.7.
Pgina 14 de 42
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:
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.
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
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.
3.8.
Pgina 16 de 42
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.
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.
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.
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.
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:
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.
Pgina 20 de 42
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.
Exclusin mutua: Mientras que un proceso accede a un recurso, ningn otro proceso accede al
mismo recurso o variable compartida.
5.1.
Pgina 21 de 42
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.
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:
Podemos clasificar el canal de comunicacin segn su capacidad, y los sentidos en los que puede
viajar la informacin, como:
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.
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
Pgina 23 de 42
por que se sincronizan los procesos ?
el SO da las instrucciones para sincronizar : con java , metodos , clases , objetos pero usa las primitivas de sincronizacion
del so que usan las librerias
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.
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?
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.
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.
Pgina 25 de 42
6.1.1.
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.
Pgina 26 de 42
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.
Pgina 27 de 42
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).
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.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.
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.
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.
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.
Pgina 29 de 42
Y, la desventaja:
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).
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.
Pgina 30 de 42
6.4.
Memoria compartida.
Pgina 31 de 42
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.
Pgina 32 de 42
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:
Para conseguir todos lo anterior contaremos con los patrones de diseo; y pondremos especial cuidado
en documentar y depurar convenientemente.
7.1.
Pgina 33 de 42
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).
Dirigida por eventos. Centrada en la produccin, deteccin, consumo de, y reaccin a eventos.
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:
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.
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.
Pgina 35 de 42
7.2.
Documentacin
una lnea
tipo C
Uso
Obligado:
Al principio de cada clase.
Al principio de cada mtodo.
Antes de cada variable de clase.
de cdigo no evidente.
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.
7.3.
Pgina 37 de 42
Dificultades en la depuracin.
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.
Para validar un programa concurrente se requiere comprobar los mismos aspectos que en los programas
secuenciales, adems de los siguientes nuevos aspectos:
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.
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?
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.
Pgina 38 de 42
Cada procesador tiene asignada la tarea de resolver una porcin del problema.
El sistema se presenta como una unidad ocultando la realidad de las partes que lo forman.
Pgina 39 de 42
8.1.
Conceptos bsicos.
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:
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.
Pgina 40 de 42
Veamos una introduccin a algunos conceptos bsicos que debemos conocer para desarrollar en
sistemas distribuidos:
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:
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 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).
8.3.
Pgina 42 de 42
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.