Académique Documents
Professionnel Documents
Culture Documents
Concurrencia
La concurrencia aparece cuando dos o ms procesos son contemporneos. Un caso
particular es el paralelismo (programacin paralela).
Los procesos pueden competir o colaborar entre s por los recursos del sistema. Por tanto,
existen tareas de colaboracin y sincronizacin.
La programacin concurrente se encarga del estudio de las nociones de ejecucin
concurrente, as como sus problemas de comunicacin y sincronizacin.
Cules son sus beneficios?
Velocidad de ejecucin. Al subdividir un programa en procesos, stos se pueden repartir
entre procesadores o gestionar en un nico procesador segn importancia.
Solucin a problemas de esta naturaleza. Existen algunos problemas cuya solucin es
ms fcil utilizando esta metodologa.
- Sistemas de control: Captura de datos, anlisis y actuacin (p.ej. sistemas de tiempo real).
- Tecnologas web: Servidores web que son capaces de atender varias peticiones
concurrentemente, servidores de chat, email, etc.
- Aplicaciones basabas en GUI: El usuario hace varias peticiones a la aplicacin grfica
(p.ej. Navegador web).
- Simulacin: Programas que modelan sistemas fsicos con autonoma.
- Sistemas Gestores de Bases de Datos: Cada usuario un proceso.
Concurrencia y hardware
Hasta ahora slo hemos hablado del software, aunque el hardware y su topologa es
importante para abordar cualquier tipo de problema.
Sistemas monoprocesador. Podemos tener concurrencia, gestionando el tiempo de
procesador para cada proceso.
En resumen:
Programa concurrente: Ejecucin de acciones simultneamente.
Programa paralelo: Programa que se ejecuta en un sistema multiprocesador.
Programa distribuido: Programa paralelo para ejecutarse en sistemas distribuidos.
Condiciones de Bernstein
Para que dos conjuntos de instrucciones se puedan ejecutar concurrentemente se tiene que
cumplir que:
La interseccin entre el conjunto de variables ledas por uno, con el conjunto de variables
que escribe el otro, debe ser nulo. Y viceversa.
La interseccin del conjunto de variables que escribe uno y el conjunto que escribe el
otro, debe ser nulo.
OCCAM
Occam es un lenguaje de programacin imperativo y estructurado (al igual que Pascal). Fue
desarrollado por David May en Inmos Limited, Bristol, Inglaterra, para desarrollar software
para su lnea de procesadores Transputers, existiendo tambin implementaciones para otras
plataformas.
Es un lenguaje de procesamiento paralelo diseado por un equipo en INMOS en conjunto
con el diseo del procesador transputer, y basado en CSP. Este lenguaje incorpora soporte
para un grano muy fino, hilos de ejecucin fciles de usar y un amplio soporte de ambientes
multiprocesadores. Este puede ser usado con sistemas de memoria compartida o distribuida,
y es una buena opcin cuando se requiere correccin[WOT01].
Java
Es un lenguaje de programacin de propsito general, concurrente, orientado a objetos y
basado en clases que fue diseado especficamente para tener tan pocas dependencias de
implementacin como fuera posible. Su intencin es permitir que los desarrolladores de
aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo (conocido
en ingls como WORA, o "write once, run anywhere"), lo que quiere decir que el cdigo
que es ejecutado en una plataforma no tiene que ser recompilado para correr en otra
1.3. LENGUAJES DE PROGRAMACIN ORIENTADOS A MENSAJES
Los sistemas de software orientados a los mensajes existen - ServiceOrientedArchitecture, y
por lo tanto, pero generalmente no corresponden a un paradigma de lenguaje, ya que
generalmente estn escritos en varios idiomas. Lenguajes orientados a los mensajes son raros
a inexistentes Si tuvieras un lenguaje que funcionara de esa manera, no slo como una
metfora, podras tener algo suficientemente basado en MessageOrientedProgramming para
complacer a AlanKay.
Cul es la diferencia entre un envo de mensaje y una llamada de mtodo? Un envo de
mensajes es dinmico, una llamada de mtodo esttico. Varias cosas se derivan de eso. Los
receptores de mensajes pueden, por ejemplo, elegir ignorar mensajes, transmitirlos o
manejarlos de diferentes maneras. El mensaje est en efecto, una peticin, no un comando.
MOP es una salida de la programacin estrictamente imperativa.
SmalltalkLanguage utiliza DynamicDispatch, por lo que est orientado a mensajes ... pero
no lo suficiente para satisfacer AlanKay. Un lenguaje funcional puede ser definido como un
lenguaje donde las funciones son ciudadanos de primera clase. Los mensajes de Smalltalks
no son ciudadanos de primera clase, separables de los envos de mensajes; No se pueden
componer pieza por pieza y su sintaxis es limitada. (Una interfaz de clase quiere ser un
lenguaje).
Un sistema distribuido que consiste en clientes que acceden a una base de datos
StructuredQueryLanguage no tiene ninguna de esas limitaciones. SQL es un lenguaje rico,
tal vez incluso demasiado rica. Las solicitudes de SQL a menudo se acumulan en varias
etapas por los clientes. El sistema est realmente orientado a mensajes, pero no es un
lenguaje.
Estoy en el proceso de completar un MOL de lenguaje orientado a mensajes que utiliza
mensajes flexibles a nivel de macro que pueden generarse mediante un comando de idioma
o mediante la creacin de una variable de mensaje de primera clase. Estos mensajes son
mapas arbitrarios (bolsas de variables) que pueden ser enviados a interfaces flexibles (en el
mismo ordenador o distribuidos) en lugar de parmetros de una funcin que estn fijados en
nmero y tipo.
En el nivel local, proveo funciones normales que usan parmetros como todos los dems
idiomas. La idea es proporcionar la flexibilidad de los mensajes a nivel macro y tambin
proporcionar la eficiencia de las llamadas de funcin a nivel local.
A veces, las ideas de lenguaje pueden llegar a blog por lo que es ms que lo que puede ser!
DavidClarkd
Hola, buen trmino. Yo estaba en el proceso de tratar de convencer a la comunidad de Python
de agregar un paradigma de paso de mensajes al lenguaje (vase tambin
PythonThreeThousand). En lugar de cien diferentes invocaciones de mtodo, pasando datos
hacia dentro y hacia fuera, usted tiene uno: un operador estndar (>> y <<) que cada clase
puede y probablemente debera tener / usar. --MarkJanssen
El reemplazo de definiciones / invocaciones de mtodos explcitos con un protocolo de
comunicaciones, llevado a su extensin lgica, le llevar de nuevo a las definiciones /
invocaciones de mtodos explcitos. Por ejemplo, cmo enviar un objeto un mensaje para
solicitar que agregue dos nmeros difiere de invocar un mtodo de objeto para agregar dos
nmeros?
Tiene un sistema de software ObjectOriented. Algunos objetos estn involucrados en un
mensaje dado (llamada de mtodo a.k.a.).
Qu objeto debe manejar el mensaje?
La respuesta MessageOrientedProgramming es "Ninguno".
Http://www.research.ibm.com/messagecentral/mop.htm
>>: Este enlace est muerto<<
Al principio, esto parece una regresin a la programacin estructurada, o poner todo el
comportamiento en una gran clase "actor", dejando todas las otras clases como bolsas de
datos. Despus de una inspeccin ms, es una reminiscencia de doble expedicin, y los
patrones como Visitante, donde un par de clases de negociar para encontrar el
comportamiento que responde al mensaje.
Entonces se parece al patrn de la fachada, con un corredor que proporciona una fachada a
todas las clases en el sistema bajo la discusin.
Finalmente, desencadena la memoria de esa cita de AlanKayOnMessaging donde habla de
lamentar el trmino "Programacin Orientada a Objetos", especficamente la parte "objeto",
ya que ahora la gente se centra en los objetos mismos, en vez de en el espacio entre ellos
Interacciones).
Hay un problema real aqu que MessageOrientedProgramming est resolviendo? O es
simplemente la gente olvidndose de protegerse con fachadas en los lugares apropiados?
Podemos secuestrar el trmino para significar, "ObjectOriented, slo dejar de mirar los
objetos ya"?
: Por supuesto puedes recrear MOP en OOP ... despus de todo puedes recrear
ObjectOrientation en ProceduralProgramming, etc, etc. TuringComplete es Turing
Complete. Pero tenemos buenas razones para no escribir todo en cdigo de mquina.
Muy pocas aplicaciones orientadas a objetos son orientadas a objetos "puros".
Eventualmente, la resuabilidad y la independencia se descomponen al mximo: el diseador
de aplicaciones crea un formulario principal, en el que todos los botones y objetos ListBox
se unen fuertemente y comienzan a referenciarse entre s.
MessageOrientedProgramacin podra ser un ejemplo de ese hbito de la Forma Principal,
pero excavar un poco ms profundo que la superficie; Usted crea una serie de objetos en su
aplicacin que todos tienen un campo 'myMainForm' en ellos, y un evento en uno de los sub-
objetos del formulario necesita dejar que los otros objetos en el formulario lo conozcan.
MessageOrientedProgramming podra considerarse una forma ligeramente menos
disciplinada de ObjectOrientedProgramming, y podra ser la misma cosa que el patrn
Mediator.
1.4. LENGUAJES DE PROGRAMACIN ORIENTADOS A OPERACIONES