El Bruno

Bruno,

disiento contigo en que el uso de threads para gestionar algo debe ser algo de último recurso.

Cada vez los procesadores tienen más y más núcleos. Actualmente tenemos procesadores con 2 núcleos y donde cada núcleo puede tener 2 procesos de ejecución simultáneos.

En 5 años tendremos procesadores de 8 núcleos en los portátiles y podremos tener perfectamente 16 procesos simultáneos de ejecución.

Si me dices que con este panorama los hilos deben ser el último recurso del programador...

Aunque sea complejo y difícil de depurar, creo que la programación multihilo debe ser una prioridad en el desarrollo de apliaciones.

Por ejemplo, en mis aplicaciones tener 4-5 hilos corriendo simultáneamente es algo normal. Tampoco es que me lo proponga, pero me sale así de forma natural.

¿Que gestione por mí las operaciones automáticamente? Nooooooo... Yo creo firmemente en las herramientas inteligentes, pero no en las que se pasan de listas...

Si ya de por sí puede ser un infierno una depuración en una aplicación multihilo, imagínate un error en una aplicación multihilo que tuviese delegada una gestión automática de todo en el framework o en las librarías usadas y no funciona como debería funcionar... Creo que te puedes hacer una idea de lo que supondría localizar un error no ya en tu código, sino en una librería del compilador o en un framework....

En mi tierra dicen "Señor, sávame de las aguas mansas que de las revueltas ya me salvo yo".

Si algún día el framework o la librería de compilador delegase de forma automática la gestión de hilos, eso pasa por poner bloqueos automáticos en todas y cada una de las variables no-locales que usemos con el impacto en rendimiento que eso supondría. Es decir, cada variable de nuestra aplicación tendría un Mutex asociado.

Supondría de golpe quitar toda posible optimización que pueda hacer el framework/compilador de almacenamiento de variables en registros.

Por mi parte es una estupenda noticia la mejora en depuración multihilo de Visual Studio. Estoy ya deseando probarlas porque la verdad que es un poco coñazo el depurar aplicaciones multihilo en el 2008.

Pero que no se pasen de frenada. Una cosa es hacer más simple la programación y otra cosa en querer que todo sea un Visual Basic 3.0 (con todos mis respetos para esa aplicación la cual usé en su día, pero no creo que a un buen programador con capacidad sobrada deba obligarsele a que el framework o compilador decida de forma automática lo que es mejor para su código).

Muy buena aportación, nos animará la existencia de estas herramientas para migrar a VS 2010, pero como tu bien dices, solo si tenemos necesidad de paralelismo, no crearlo por crearlo

Un saludo Bruno

Buenas, y llegó el 10mo recopilatorio con los posts que voy escribiendo sobre las novedades de

Buenas, 11vo recopilatorio con los posts que voy escribiendo sobre las novedades de Visual Studio 2010

Buenas, nuevo recopilatorio con los posts que voy escribiendo sobre las novedades de Visual Studio 2010