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".

[Mick]

No entiendo algunos de los puntos que se plantean:

-Si no se permite compartir la memoria, el sistema no es multihilos, se convierte en un sistema normal de multiprocesos que ya existe y se utiliza desde hace mas de 20 años. Una de las razones principales y que definen el sistema de multihilos es precisamente que la memoria sea compartida, lo que permite que crear nuevos hilos de forma mucho mas rapida que el sistema anterior de multiprocesos.

-Si no se pueden hacer bloqueos no se podra utilizar el sistema para casi nada, solo valdria para procesos independientes, pero en la practica , es imprescindible poder hacer bloqueos, porque siempre habra unos procesos que tengan que esperar por otros, por ejemplo porque tengan que utilizar los resultados de los calculos de otros procesos, etc.

Saludos

[mamcx]

Lo que dices es valedero para la implementacion tradicional. Pero el punto es que la forma de afrontar este problema es fundamentalmente erroneo.

Por eso es bueno leer el articulo del porque ErlLang toma una ruta diferente.

Ya que no se comparte la memoria, se parece a un modelo de procesos y de hecho asi se denomina en ErLang, sin embargo no son procesos tal como se define en los OS, es mas bien un sistema de hilos diferentes. La informacion de desempeño de ErlLang atestigua que es un esquema muchisimo mas escalable y que consume menores recursos...

El segundo problema... no lo es. Los bloqueos es una forma compleja de resolver los problemas, pero no es la unica. Por ejemplo, Windows permite enviar mensajes (y asi se implementan los click, click derecho, movimientos del mouse, e infinidad de cosas) y de paso usar este mecanismo es algo que he visto como recomendado. Usando el sistema de mensajes de Windows junto con threads es una forma que resuelve muchas dificultades.

El que tenga estas caracteristicas es lo que lo haria aun *mas* usable.

La experiencia muestra que casi todo el mundo logra captar como programar en ambientes sin-estado como en paginas web, en contraste, casi nadie hace programacion multi-hilos/procesos porque es muy complejo.

Y sinceramente, no se me ocurre como este esquema no podria aplicarse en los casos donde multicore/hilos es util, quizas lo unico es que la informacion hay que serializarla y deserealizarla como ocurre en un sitio web o con servicios web, pero en la practica no es un problema tan duro de resolver frente al problema de base que es la aplicacion de funciones paralerizables.