RETO: Implementar multihilos de forma inteligente

[mamcx]

Ok, aqui les va el primer reto.

Problema:

Como todos sabemos, o estaremos enfrentados dentro de muy poco, se acabo la comodidad de la programacion "unicore"/Un solo procesador.

Se acabo la "comida gratis"

http://www.gotw.ca/publications/concurrency-ddj.htm

Lo que quiere decir que es importante que para quienes queramos hacer software competitivo para los proximos años y teniendo en cuenta que los procesadores multi-core ya son vendidos al publico en general, y que la ENORME mayoria de los programas escritos bajo la suposiciones de la era de la Ley de Moore y un unico nucleo son muy ineficientes sobre este "nuevo" (no lo es tanto) paradigma, es importante que nos enfrentemos a la realidad: Hay que aprender a hacer software multi-core.

Solucion actual:

El problema es que no es nada simple. Llevo como 10 años de experiencia y soy capaz de entender muy bien como hacer y leer una expresion regular (que estan escritas de forma muy criptica) y un monton de conceptos pero sinceramente, jamas he podido entender como *implementar* la capacidad de multi-hilos.

He leido tutoriales. He leido la ayuda. Me he bajado componentes. Nada. No me entra el condenado concepto... no me llega la iluminacion y estoy deprimido... despues de 10 años y no soy capaz!

Estoy seguro que para muchos, es asi de problematico.... y no me refiero a saber usar TThread y Sincronize, eso es facil, es que simplemente no me entra como usar de verdad eso.

Usar Tthreads, semaforos, mutex, secciones criticas... es como programar pointer pero mas dificil (los pointer los entiendo al menos!)


Solucion propuesta:

Entonces, encontre el camino, gracias a un lenguaje desconocido: ErLang.

http://defmacro.org/ramblings/concurrency.html

Y este es el reto:

Implementar una serie de funciones y clases que:

1- No requiera hacer bloqueos. Saber "bloquear" en threads es muy enredado y propenso a errores. Los señores de ErlLang simplemente ignoran esto... y es muy listo de su parte!

2- No permita compartir objetos en memoria, o por lo menos, promueva no hacerlo

La idea es algo como las clases de "sesion" y "aplicacion" de un webserver. Alli va la memoria, no en una variable global que pueda generar errores de concurrencia y problemas de interbloqueo y racing

3- Sea state-less

Punto

4- Sea facil de codificar y de escribir.

La API que propongo es algo como:

Código Delphi [-]
//1. Metodo paralerizable. Implementar como un procedure?

// SoyParalerizble debe ser capaz de trabajar con datos serializables y de forma sin-estado / stateless
procedure SoyParalerizable(PID:Integer;Msg:array of const);
begin
    //Aqui un ciclo que sume cosas por ejemplo...

   //Enviar datos
end;

// 2. Paralelizar:

// Fork se encargaria de armar/añadir al pool de hilos los procesos y de retornar de forma *asincronica* el listado PIDS o ID de proceso...

PIDList: = Fork([SoyParalerizable,[1,2]], [SoyParalerizable,[3,4]], [SoyParalerizable,[5,6]]);

3. Enviar datos

En cualquier lugar:

EnviarMensaje(PID,[5])
BroadCast(PIDList,'Finalizen');
BroadCast([1,2,5],'Finalizen');

3. Recibir Mensajes:

procedure CaptarMensaje(PID:Integer;Sujeto:String;Msg:array of const);
begin
     if Sujeto = 'Finalizen' then
     begin
         Muere(PID);
         Log('Proceso ' + PID + ' finalizo');
     end;

     if Sujeto = 'Completo' then
     begin
         Log('Proceso ' + PID + ' completo. Resultado: ' +....
     end;

end;

Es una idea muy rustica, y el API se puede "embellecer".

Ahora, miren este codigo:

http://groups.google.com.co/group/bo...638fd2bd49eaf0

(Bajen hasta que lo vean)

Ese codigo se llama MAP/Reduce y es una tecnica maestra que implementa google.

En fin, el challenge es:

- La sintaxis "ideal" que nos permitiria trabajar naturalmente con multihilos tal como lo hacemos con eventos y otras cosas

- Una idea de implementacion. Para quien se le mida, le recomiendo *altamente* que mire Decal (http://sourceforge.net/projects/decal) y/o DCL (http://sourceforge.net/projects/dclx) este ultimo ya es parte de la JCL.

Como lograrlo:


Para hacerlo:

1- Lean sobre como lo hace ErlLang... es increible que una idea tan simple no se haya hecho antes

2- Que es MAP/Reduce, es un camino corto a la solucion

3- Que es DECAL/DCL. Tienen la solucion de MAP/Reduce y hacen cosas "magicas" que les dejo de tarea

4- Minimamente, como les *gustaria* que fuera este tipo de programacion. Este reto es mas sobre "como deberia ser".