Concurrent Programming in ERLANG

Concurrent Programming
in ERLANG
Second Edition
Joe Armstrong
Robert Virding
Claes Wikstr¨om
Mike Williams
Ericsson
Telecommunications Systems Laboratories
Box 1505
S - 125 25 ¨ Alvsj¨o
Sweden
PRENTICE HALL
Englewood Clis, New Jersey 07632




Parte 1 subido mediafire descarga de aqui

Articulo Erlang

Date Arrow December 19, 2007

As I said before, I like to learn a new programming language every year. I also like to read at least 6 computing-related books every year, but the article about those 6 will come later.

The reason for these two rules is twofold: first, it gives me lots of material to blog about, and helps me refine my list of preferred languages :) secondly, and more seriously, learning a new programming language makes you think differently about problems. It’s not just something to keep my CV updated; it’s to challenge what I know, how I know it, and why I know it. It is important, and it’s not easy; and I’m not the only one to do it.

From all the candidates that I had for this year, I chose to learn Erlang. Here’s some of my impressions.

Erlang is a functional programming language, created by Joe Armstrong (photo) at Ericsson in the 80s. The name of the language is a pun between the name of the Danish mathematician Agner Krarup Erlang and the acronym “ERicsson’s LANGuage”. By the way, lots of things are coming from Denmark lately.

The main factor that made me jump on this wagon was that the language got a lot of attention, both in 2006 and 2007. The peak of all this buzz was a couple of days ago, when Amazon unveiled a new online service called SimpleDB, apparently built with Erlang. The reason for this is Erlang’s inherent capability to handle massively parallel programming relatively easily. In Erlang you can create lightweight processes, each sending messages to the others, and thus divide your problems in small units that run concurrently.

Even more buzz, the release of the Pragmatic Programmer’s book about Erlang (written by Joe Armstrong himself) has added a strong factor to the recent popularity of the language.



How to start with Erlang?

1. Get it working on Leopard using MacPorts;
2. Activate the Erlang language support in TextMate;
3. Follow a quick tutorial to get the idea;
4. Check out the Yaws web server build on Erlang, apparently much, much stronger than Apache under high load!;
5. Download, install and play with ErlyWeb, an MVC framework similar to Rails;

More interesting reading (and viewing) about the language:

* Erlang: the Movie;
* What’s all this fuss about Erlang?, by Joe Armstrong;
* Web 2.0: Shifting from “Get Fast” to “Get Massive”;
* Concurrency is easy, in Joe Armstrong’s blog;
* More Erlang, by Yariv Saran, a guy who really knows about Erlang;
* An Introduction to Erlang on the ONLamp.com O’Reilly’s website.

My del.icio.us link list about Erlang will keep growing… subscribe to the RSS feed to get updated of new entries on your favorite reader.

In spite of some opinions that I have seen about Erlang so far (please check a question I’ve asked at LinkedIn about it), I have found this language extremely interesting; and at the moment, my list of known programming languages goes like this:

* 1992: QBasic; it came bundled with my first PC!
* 1993: Turbo Pascal; it was part of the official curriculum in the University of Geneva.
* 1994: C; my first contact with the bracket syntax.
* 1995: Delphi; I preferred more the Pascal syntax at that time… and it was an amazing environment to work with.
* 1996: Java; everybody was talking about it at the time! You couldn’t miss it.
* 1997: JavaScript; adding interactivity to web pages was the coolest possible thing to do at the time!
* 1998: VBScript; that’s when I started working with MS’ ASP technology;
* 1999: Transact-SQL; those ASP pages were talking to a SQL Server 6.5 in the background…
* 2000: C# and Prolog; the first was the coolest thing since sliced bread (remember the technology previews back in August 2000?), and the second, part of the official curriculum at the Universidad de Buenos Aires…
* 2001: C++; I had to learn it. It’s a major step in anyone’s career.
* 2002: PHP; my jump to the open source world started here…
* 2003: Objective-C; after I became a “switcher”, I installed the free developer tools that came with Mac OS X… and never looked back!
* 2004: Visual Basic.NET; stuff that some clients required me to learn… geez.
* 2005: Ruby; my flirting with Rails started that year.
* 2006: LINQ; a language inside a language: or how to use C# to filter collections in-memory as if they were small databases…
* 2007: Erlang; here I am now!


sacado de http://kosmaczewski.net/2007/12/19/erlang/

Lenguaje ERLANG

Es un lenguaje funcional, con evaluación estricta, asignación única, y tipado dinámico. Fue diseñada en la compañía Ericsson para realizar aplicaciones distribuidas, tolerantes a fallos, soft–real-time y de funcionamiento ininterrumpido. Proporciona el cambio en caliente de código de forma que este se pueda cambiar sin para el sistema. Originalmente, Erlang, era un lenguaje propietario de Ericsson, pero fue cedido como open source en 1998.

La implementación de Ericsson es, principalmente interpretada pero también incluye un compilador HiPE (solo soportado en algunas plataformas). La creación y gestión de procesos es trivial en Erlang, mientras que, en muchos lenguajes, los hilos se consideran un apartado complicado y propenso a errores. En Erlang toda concurrencia es explicita.

Erlang recibe el nombre de A. K. Erlang. A veces se piensa que el nombre es una abreviación de Ericsson LANguage, debido a su intensivo en Ericsson. Según Bjarne Dacker quien fue el jefe de Computer Science Lab en su día, esta dualidad es intencional.

Limbo es un lenguaje de programación para escribir sistemas distribuidos. Además es el lenguaje usado para escribir aplicaciones para el sistema operativo Inferno. Fue diseñado en los Laboratorios Bell por Sean Dorward, Phill Winterbotton y Rob Pike.

Situación de bloqueo. Función de Erlang B

Se define la situación de bloqueo como aquella en la cual todos los servidores están ocupados. En estas circunstancias, cuando llegue una nueva unidad, no podrá ser atendida y, al no disponer de cola de espera, se perderá.
De acuerdo con esta definición, se puede calcular la probabilidad de estar en esta situación de bloqueo por identificarla con estar con todos los servidores ocupados, puesto que en este caso la llegada de una nueva unidad provoca irremediablemente su pérdida. En suma, la probabilidad de bloqueo coincide con la probabilidad del estado m, y es lo que se define como función de Erlang B usando la siguiente expresión de probabilidad:



Así pues, la función de Erlang B no es más que la probabilidad de bloqueo de un sistema M/M/m/m,
es decir, de un sistema formado únicamente por servidores, sin cola de espera.
Este tipo de cola modela perfectamente el acceso a los circuitos de una central telefonía. Por ello,
Erlang B es un modelo típicamente empleado para el dimensionado de sistemas basados en
conmutación de circuitos.
Si a es el tráfico ofrecido (TO) al sistema, queda claro que a·Pm (= a · Er1(m,a)) debe ser el tráfico
perdido (TP). Dado que el tráfico cursado (TC) es la diferencia entre el ofrecido y el perdido (TC =
TO – TP), se tiene que TC = a (1-Er1(m,a)), tal como muestra la figura




También se puede obtener fácilmente que el número medio de unidades en el sistema es



que es precisamente el tráfico cursado en el sistema.

La cola M/M/m. Erlang C

Modelo de cola
Al igual que para los sistemas anteriores, considérese una tasa de llegadas 􀁏 y una tasa de servicio , en un servidor. Cada estado representa el número de unidades en la cola de espera.

Como se desprende de la notación, el sistema que ahora se va a estudiar dispone de únicamente m servidores, con cola infinita.

En consecuencia, puede haber hasta m unidades atendidas simultáneamente y un número ilimitado esperando en cola. Nótese que la primera unidad que formará cola es la que ocupe el ordinal m+1. En este caso, el modelo de cola coincide con el de M/M/ hasta el estado m-ésimo, dado que hasta este momento, la situación es la misma.
Sin embargo, a partir de la llegada de la unidad m+1, ésta no será atendida y pasará a esperar su turno en cola. En consecuencia, cuando el estado del sistema sea superior a m, todos los m servidores estarán activos, y por tanto, la tasa de servicio para los estados superiores a m será m·. Por otro lado, las
llegadas se producen a tasa , independientemente del número de unidades en el sistema ésa será la tasa de nacimientos, y así se pone de manifiesto en la cadena representada en la figura

Ejercicios de Trafico

1 ) Si un aparato telefónico cursa un día 27 llamadas, cada una de las cuales tiene una duración de 5 min. (como termino medio), el volumen de trafico será:

Vt=n*d=27*5 min=135 min.
Vt=135 min*60 Seg.=8.100 Seg.
Vt=8.100 Seg.*(1 LL.R./120 Seg.)=67'5 LL.R.
Vt=8.100 Seg.*(1 C.C.S./100 Seg.)=81 C.C.S.

Calcular además la intensidad de trafico si se observo durante un día.

It=Vt/tobs=(8.100 Seg./24 horas)*(1 hora/3600 Seg.)=0'09375 E
It=0'09375 E*((30 LL.R./H.C.)/1 E)=2'8125 LL.R./H.C.
It=0'09375 E*((36 C.C.S./H.C.)/1 E)=3'3375 C.C.S./H.C.

2 ) Si 5 órganos de una central de conmutación cursan cada uno de ellos 32 llamadas de una duración media de 2 min. cada una, el volumen de trafico será:

Vt=N*n*d=5*32*2 min.=320 min.
Vt=320 min.*(60 Seg./1 min.)=19.200 Seg.
Vt=19.200 Seg.*(1 LL.R./120 Seg.)=160 LL.R.
Vt=19.200 Seg.*(1 C.C.S./100 Seg.)=192 C.C.S.

Calcular además la intensidad de trafico si se observo durante 1 hora.

It=Vt/tobs=19.200 Seg./3.660 Seg.=5'33 E
It=5'33 E*((30 LL.R./H.C.)/1 E)=160 LL.R./H.C.
It=5'33 E*((36 C.C.S./H.C.)/1 E)=192 C.C.S./H.C.

ENCAMINAMIENTO DE TRAFICO. NORMAS O CRITERIOS

Como la Red Complementaria se superpone a la Red Jerárquica, el camino para conectar 2 abonados entre si puede no ser único. Por tanto pueden aparecer varias rutas alternativas u opciones a la ruta final.

Esto supone que es más difícil que una llamada se pierda por no existir caminos libres, pero supone la necesidad de tomar decisiones sobre el encaminamiento de la llamada, ya que debemos elegir un camino entre todos los que están libres.

La decisión del encaminamiento se toma en cada una de las centrales implicadas en la llamada. Cada central toma la decisión del encaminamiento teniendo en cuenta el destino final de la llamada, y según uno y solo uno de los siguientes criterios de encaminamiento.

-Criterio nº 1
Si entre la central donde se decide el encaminamiento y la central de destino final de la llamada existe una sección directa, se encaminara el trafico por esta como primera opción. Aquellas llamadas que no puedan ser cursadas por esta sección directa (TRAFICO DE DESBORDAMIENTO), lo harán por sección final correspondiente.

-Criterio nº 2
Solo se aplica si no puede usarse el primer criterio. Si existe sección directa entre la central donde se decide el encaminamiento y una central que sea, por red Jerárquica, de rango superior a la central de destino final de la llamada, se cursara por esta, y el trafico de desbordamiento se cursara por la sección final correspondiente. Si existen varias secciones directas que cumplan esta condición, se hará por la mas corta. El trafico que una sección directa no pueda cursar, nunca se cursara por otra sección directa, sino por sección final.

-Criterio nº 3
Solo se aplicara cuando no pueden aplicarse ni el primer ni el segundo criterio. Se encamina el trafico como única opción por la sección final correspondiente. El trafico que dicha sección final no pueda cursar, no podrá encaminarse y constituirá lo que se denomina TRAFICO PERDIDO.

Sobre estos criterios deben resaltarse los siguientes puntos:

a ) El encaminamiento se hace desde el abonado A al abonado B, haciendo los tránsitos necesarios en las centrales intermedias.

b ) Cada central tomo uno y solo uno de los criterios anteriores. Si no puede tomar el primero tomara el segundo, y si no puede tomara el tercero

c ) Cuando se aplique el primer o segundo criterio, tendrá que estudiarse por separado cada uno de los caminos que se obtienen como opción.

d ) La alternativa a una sección directa nunca es otra sección directa.

e ) Las centrales que toman decisiones de encaminamiento dependen del origen y destino de la llamada, y de las decisiones de encaminamiento previas.

f ) Se tomaran con preferencia las secciones directas por los que los encaminamientos sean mas cortos.

Ejemplo:
Vamos a encaminar una llamada desde N a P en la red de la figura siguiente:
Si solo existiera la Red Jerárquica el camino seria único e igual al de la ruta final.

RUTA FINAL: N-H-D-A-B-E-I-P





1ª alternativa: N-H-P
2ª alternativa: N-H-D-I-P
3ª alternativa: N-H-D-A-E-I-P
RUTA FINAL : N-H-D-A-B-E-I-P




Veamos también el encaminamiento entre M y P



1ª alternativa: M-G-C-A-E-I-P
RUTA FINAl : M-G-C-A-B-E-I-P

Veamos también el encaminamiento entre P y N




1ª alternativa: P-H-N
2ª alternativa: P-I-H-N
3ª alternativa: P-I-E-D-H-N
4ª alternativa: P-I-E-B-D-H-N
RUTA FINAL : P-I-E-B-A-D-H-N