[mamcx]

Empezado por matabyte

No se que tendras contra delphi, pero como te he dicho arriba, desde hace 5~10 años se puede programar de forma natural y productiva y sin quebraderos de cabeza e incluso elegir el/los nucleos con los que quieres trabajar, etc...

Ok, empecemos por algo. No estoy diciendo que no sea posible hacer multi-hilos al dia de hoy, o que este en contra de Delphi. No es mi opinion personal, es el consenso de la industria y de programadores mas experimentados en este tema (ie: Los que les toca la parte compleja del asunto). La cosa es que la optica de si es natural o productivo o quebraderos de cabeza cambia radicalmente desde donde lo estes viendo. Al igual que muchos, uso *algo* de la programacion multi-hilos/procesos (aun mas con obj-c, donde es mas natural que con Delphi) pero ni a leguas estoy del punto donde pueda sacarle el jugo a todo...



Algunos articulos sobre el tema:

(Este fue el primer campanazo del que me entere)
http://www.gotw.ca/publications/concurrency-ddj.htm

(Nota que esta es una discusion de porque los Threads son considerados como dañinos, y que en general se deben evitar de ser posible)
http://c2.com/cgi/wiki?ThreadsConsideredHarmful

Empezado por matabyte

No me digas que los Threads es algo que rara vez usamos los programadores... eso seria hace 10 años.... Porque cualquier tarea compleja que no se haga en segundo plano con un Thread te va a congelar la ventana, cosa que a los usuarios no les gusta mucho la verdad... Por no hablar de interconexion a varias bases de datos en distintas webs (un thread por cada conexion), o de un server (un thread por cada socket), etc...

El asunto en si resulta dificil de apreciar, principalmente es un problema de escala y de enfoque. Por ejemplo, no es el mismo problema hacer un motor de bases de datos/servidor web de alto desempeño que hacer que una consulta SQL de un programa contable no bloquee la GUI.

Me arriesgare a suponer que lo de multi-hilos, por los comentarios que expones, se concentra en hacer un GUI que no se congele y no se va mas lejos que tener unas pocas tareas, y que esto ademas, es ppalmente programar asíncronamente, ej: Ejecuta este SQL en este hilo, voy haciendo otras cosas, luego recibo el resultado y actualizo la GUI. Este es el modelo mas común ahora y mas simple de todos (en cuanto a tener multihilos). De hecho, es un modo de programación simple porque todo lo asincrónico se puede escribir sequencial, se puede colocar en un queue y es solo cosa de tener callbacks y todo eso. Es ligeramente mas difícil que la secuencial, pero no mas difícil que la programación por eventos.

Empezado por matabyte

Definitivamente no XD.

Todos esos "problemas" y ese "monton de cosas que hay que hay que hacer" que dices que hay que hacer son exactamente los mismos que a la programación para un solo núcleo XD.

Para nada! Los mismos? Este es uno de los puntos de mas shock, es que pocos entienden lo difícil que es paralelizar las cosas:

http://www.futurechips.org/tips-for-...ogramming.html

La programacion multi-hilos/cores implica:

1- Una cosa es poder lanzar n-tareas en un hilo/proceso aparte, y esperar su resultado (osea asincrónico y relativamente facil). Este modelo tiende a ser ineficiente porque no utiliza los cores de la CPU de forma optima. Es una derivacion de la programacion sequencial, ligeramente dificil de depurar y de hacer bien (con 1-4 tareas de fondo, pan comido, una vez empiezas a tener decenas, cientos.....)
2- La capacidad de paralelizar una tarea (ie: si tarea A toma 100sec con 1 core, deberia tomar 25secs con 4). Jodidamente difícil de hacer a veces, porque por razones físicas y teóricas un montón de cosas no se pueden paralelizar.
3- Comunicacion y coordinacion entre tareas. AQUI es donde estan, por mucho, los ppales dolores de cabeza. Dependiendo de la dificultad de esa comunicacion, y de cuantos bloqueos hayan, sera mas o menos dificil de hacer y depurar
4-Limpieza de tareas y recursos vivos. Matar hilos es cosa maluca, y complicada de hacer correctamente bien.

Empezado por matabyte

Pues que quieres que te diga, no es algo que sea dificil de hacer, o soy un genio o no es tan difícil de hacer las cosas sin bugs. Si te es difícil hacer un código usando Threads sin errores, olvídate de programar aplicaciones de tipo cliente/servidor, bases de datos, juegos y demás.

Como todo, dependen del nivel de complejidad en el que estas. Puedes leer un hilo de la gente de synapse sobre complicaciones, consideraciones y demás dificultades relacionadas con la tarea. La parte importante es notar la cantidad de consideraciones, peros, condiciones y entendimiento que hay que tener para llegar a donde se quiere:

http://synopse.info/forum/viewtopic.php?id=57

Obvio, ese es lo que ven quienes hacen a synapse, no quienes lo usan. El problema es que cuando los que lo usan empiezan a subir de nivel, se van a enfrentar a problemas para los cuales no están preparados.

Esto no es especifico de Delphi. Con obj-c/Coccoa que tiene un soporte superior para este paradigma, es casi igual de dificil. Lo mismo C#, y Java, etc.

El principal problema es de la comunicacion, y el manejo de estado
http://gregbeech.com/blog/threading-...-state-is-hard

Cuando se hace programación asincrónica, quizás no se tope uno con eso, porque se envia el objeto/datos a la tarea de fondo y se recibe otro objeto/datos (o no se modifica por fuera de la tarea) y por eso todo sale fácil.
------------------------------------------------
Hasta aquí todavía puede que uno se sacuda la cabeza y no le vea el alboroto a todo esto, aparte de unos cuantos tipos que dicen que es difícil, pero que a uno no le parece tanto. Es como todo. Cuando lo que se usa en assembler uno no le ve cual es la gracia de un lenguaje de mayor nivel. Cuando obj-c gano la posibilidad de no manejar manualmente la memoria, había un MONTON de gente que decía "y que problema hay con hacerlo manual?" y así por el estilo.

Existe un limite a cuantos threads se pueden crear (http://blogs.technet.com/b/markrussi...8/3261309.aspx =55,000 en 64bits) aunque realistamente es MUCHO menor. En contraste, algo como erlang puede manejar 268'435.456.