La vida privada de volatile

El estándar de C(++) tiene unas cuantas esquinitas. Seguramente volatile es una de ellas. Para aclarar el significado exacto de este calificativo en Coding Relic han publicado La vida privada de volatile, en donde no solo se analiza la letra del estándar sino que se examina el código generado para MIPS en distintos casos.

Conviene recordar los posibles usos de volatile, así como para qué no debe usarse:

• How does the C "volatile" keyword really work? de Ian Lance Taylor. El resumen es bastante claro

  If you are using volatile for anything other than manipulating memory mapped hardware, or for very limited communication between threads, it is very likely that you are making a mistake. Think carefully about what volatile means and about what it does not mean.

• En la misma linea, Volatile: Almost Useless for Multi-Threaded Programming
• Varias discusiones en usenet: C++, volatile member functions, and threads, volatile guarantees? y Memory Barriers, Compiler Optimizations, etc., todas ellas en comp.programming.threads
• Una discusión sobre lo que es, que no es y que quizás debiera ser volatile en Should volatile Acquire Atomicity and Thread Visibility Semantics?, lo que lleva a arreglar el modelo de memoria de C++.

La vida privada de volatile en barrapunto

Programando con threads: algunos enlaces

Algunos enlaces a tener en cuenta si programas con threads:

• "Avoid Calling Unknown Code While Inside a Critical Section" por Herb Sutter. Como simepre, las secciones críticas cuanto más pequeñas mejor, pero además conviene saber qué es lo que se llama en ellas... (Me recuerda un poco al mantra Trata el código de los demás como si fuese tuyo)
• "Single Threaded Memory Model" de Ian Lance Taylor: como comentaba hace ya mucho en Los peligros de programar con threads el compilador puede llegar a hacer optimizaciones que den al traste con la intuitiva atomicidad de algunas variables cogidas por mutex. Pues bien, aparentemente ese problema que podría parecer remoto se puede reproducir con gcc. La solución, como siempre, conocer bien el estándar y el uso de volatile. De todos modos queda patente que se necesita algo parecido a un modelo de memoria que tenga en cuenta la concurrencia, como se comentaba también en Threads y C++(estándar)

Programando con threads: algunos enlaces en barrapunto

Varios sobre concurrencia: JVM, clasificaciones y consejos

Una ración de enlaces relacionados con la programación concurrente:

• El título lo dice todo: Where the metal meets JVM (An interview with Cliff Click) (Encontrado vía Pensamientos ágiles) Interesantísimo repaso a la implementación de la concurrencia en la máquina virtual de Java y de su relación con el hardware subyacente, con sutilezas en cuanto al modelo de memoria de cada arquitectura. Una buena conclusión, después de leerlos sería: no te fíes de que funcione, estudia bien las especificaciones, no vaya a ser que te lleves sorpresas con el run anyware ;)
• Gracias a sammael, dos artículos sobre también sobre el mismo tema: Introduction to nonblocking algorithms y Synchronization optimizations in Mustang, ambos de Brian Goetz. Un vistazo a java.util.concurrent y algunos detalles sobre el presente y futuro de la concurrencia en java. Complementarios al anterior.
• Herb Sutter en "How Much Scalability Do You Have or Need?" vuelve a clasificar las soluciones para aprovechar la concurrencia del hardware; en este caso se clasifica mediante la escalabilidad que se necesita, desde usar un solo core hasta la explotación de todos los recursos disponibles.
• "10 Ways to Reduce Lock Contention in Threaded Programs" de Michael Suess, que también cita a Goetz. Tanto el primer enlace como éste subrayan la dificultad de pasarse de listo y tratar de programar sin bloqueos. Aquí se califica de optimización prematura y se proponen alternativas muy interesantes como granularizar los bloqueos (y evitar el big lock que seguramente debería ser la primera implementación...) o usar bloqueos de lectura o de escritura (si están disponibles y es posible). Se trataría del primer paso (los primeros diez pasos) en la optimización

Varios sobre concurrencia: JVM, clasificaciones y consejos en barrapunto

Un vistazo a Threading Building Blocks

Según se puede leer en Ars technica: Intel open sources multicore programming tool Intel libera Threading Building Blocks, una herramienta hasta ahora propietaria que ayuda a la programación concurrente. La noticia ha salido en muchos sitios con comentarios interesantes (Slashdot, OSNews o en barrapunto)

Había oído hablar de esta herramienta en la entrevista a Sanjiv Shah de OpenMP en thinking parallel, pero como él trabaja en Intel siempre parece más sospechoso tratándose de un producto comercial. Ahora que lo han liberado he estado echándole un vistazo y bueno, creo que tiene su ámbito de aplicación y que puede ser muy interesante para facilitar algunas tareas sin reinventar alguna rueda.

Por analizar un poco la librería, consta como de cuatro partes:

• Algortimos para bucles paralelos: parallel_for, parallel_reduce, parallel_while. Me ha parecido de lo más interesante de la librería porque es muy fácil de implementar y te ahorra mucha gestión. Al algoritmo se le pasa un contenedor sobre el que operar y un functor y el lo procesa en paralelo automágicamente, aunque parece ser algo parametrizable.
• Contenedores seguros a accesos concurrentes: concurrent_hash_map, concurrent_vector, concurrent_queue. Usan internamente los bloqueos de grano fino y estructuras de datos sin bloqueos. Que bien que no haya que hacerlo por uno mismo, tiene pinta de ser complicadillo y muy fácil hacerlo mal
• Utilidades para gestión de la concurrencia: mutexes de diverso tipo (si, recursivos también), locks, operaciones atómicas
• Un gestor de tareas: una ayuda para programar orientado a tareas, threads más ligeros que los del sistema.

Desde que lo han hecho opensource le han asignado un domino propio, http://www.threadingbuildingblocks.org/ en el que hay bastante información. En particular el tutorial al que le he echado un vistazo es Intel® Threading Building Blocks: Tutorial

Por dar alguna nota no positiva... bueno, de momento solo soporta plataformas desde Intel Pentium 4, porteriores y compatibles, aunque en una de las FAQ del proyecto dicen que soportar todos los procesadores, sistemas operativos y compiladores es una las piedras angulares del proyecto. Veremos.

También me ha llamado la atención que dijesen (extraído del artículo de ars technica):

Java and .NET versions of TBB are currently being evaluated by Intel, and may eventually be announced. But Intel maintains that C++ is the company's priority, and it's where they'll be focusing the engineering resources that they're adding to the project.

Puede ayudar a hacer un poco más multiplataforma el código paralelizado en C++, aunque ya existen muchas librerías que lo hacen, como Boost.Thread. Supongo que estará bien usarlo cuando se necesita mucho rendimiento, una aproximación más sencilla no vale y paralelizarlo de este modo sale rápido y óptimo.

Un vistazo a Threading Building Blocks en barrapunto

Entrevista sobre YARV

Vía la sección de reddit de programación (que a pesar de su sistema de filtrado y puntuación, también tiene el mal del exceso de información... ) he encontrado una serie de entrevistas sobre la nueva máquina virtual que ejecutará Ruby: YARV. Responden las dos personas más involucradas en ello, Matz (recordemos, el creador del lenguaje) y a Koichi Sasada, el desarrollador principal.

En la segunda parte de la entrevista se habla de las distintas implementaciones de los entornos de ejecución de Ruby. Por resumir, Koichi dice: "Necesitamos especificaciones, buenos test y buenos benchmarks". Por las bitácoras de barrapunto se ha hablado de ello, porque Robert h Quinn está trabajando en los test, según comentaba en GSoC 2007 : De que va mi proyecto

Sobre todo me ha gustado la tercera parte, sobre el pasado el presente y el futuro de los threads en Ruby.En esta parte se argumentan las razones por las que se abandonó la implementación de threads en espacio de usuario por el uso de los threads nativos del sistema, además de explicar como eso afecta el soporte de continuaciones.
(Hablamos de estas cosas hace unos meses en Noticias sobre Ruby 2.0 (que al parecer no son sobre 2.0 estrictamente...)

Actualización: Como me comenta Robert h Quinn, en On Ruby tienen una serie de entrevistas a los desarrolladores de distintas implementaciones de entornos de ejecución de Ruby. Más para leer...

"Entrevista sobre YARV" en barrapunto

Entrevistas a gurús de la programación paralela

En el estupendo blog Thinking Parallel, se ha comenzado una serie muy prometedora, entrevistas a gurús de la programación paralela, gente que ha diseñado sistemas que la soportan, la facilitan y/o la potencian: Joe Armstrong de Erlang, William Gropp de MPI, Sanjiv Shah de OpenMP, David Butenhof de los threads POSIX (de quien ya se ha hablado por aquí en Diseño sencillo contra implementación correcta) Además promete intentar entrevistar a los responsables de los threads de la JVM y del .NET framework. Las entrevistas son por correo y tienen la particularidad de que son las mismas para todos ellos, cinco preguntas sobre el la programación paralela en general y cinco preguntas sobre su sistema en particular.

De momento ha publicado ya dos, muy interesantes: Ten Questions with Joe Armstrong about Parallel Programming and Erlang y Ten Questions with William Gropp about Parallel Programming and MPI.
Actualización: Se ha publicado la tercera entrega: Ten Questions with Sanjiv Shah about Parallel Programming and OpenMP

Extractando. Joe Armstrong:

• Sobre balas de plata: Si, las infraestructuras puras de paso de mensajes resolverán muchos problemas (cosas como el servicio de cola simple de amazon(?)). Es una vuelta a la programación basada en flujo de Paul Morisson
• Comparando la programación paralela con la secuencial: No es más difícil - es difícil debido al modelo dominante de bloqueos, threads y memoria compartida, que si es dificil. Los sistemas puros de paso de mensajes son más fáciles de programar y de comprender

William Gropp (más pragmático al parecer):

• Sobre mensajes contra memoria compartida: Ambas tienen virtudes y defectos. El paso de mensajes traspapasa la gestión de las estructuras de datos distribuidas al programador. La memoria compartida requiere un gran cuidado para evitar condiciones de carrera y bugs de rendimiento (como la falsa compartición). Ninguno es un modelo de programación completo. Hemos tenido y seguiremos teniendo acaloradas discusiones(*) sobre las deficiencias de ambos.

(*)también conocidas como flames :)

Actualización: Sanjiv Shah:

• Ahondando más en el tema de paso de mensajes contra memoria compartida:Decidir cual es apropiada depende muchísimo de la aplicación: la memoria compartida facilita unas cosas y la memoria distribuida otras. SETI@home es ahora el ejemplo clásico: apenas se comparten estados entre todos los ordenadores que están ejecutándose a lo largo del mundo independientemente. Muchas aplicaciones de este estilo usan memoria distribuida de modo natural. Por otra parte cuando hay muchos cambios de estado que se deben compartir, el uso de memoria compartida tiene mucho sentido.

Entrevistas a gurús de la programación paralela en barrapunto

¿Estructuras de datos sin bloqueos?

En una entrada en su blog, Lock-Free Datastructures, Ulrich Drepper duda de la aplicación actual de estructuras de datos compartidas y sin bloqueos sin implementar un gestor de memoria personalizado. No obstante viene a decir que esto cambiará en un futuro próximo...

Por otro lado otros, menos pragmáticos, aconsejan una vía hacia la iluminación que incluye el paso por esos senderos, advirtiendo, eso si que hay que cambiar de un modo de pensar centrado en el lenguaje a uno centrado en la arquitectura (me pregunto yo si merece la pena perder la preciada portabilidad) Hay a algunos que si les merece la pena: Tom Leonard de Valve

Y por supuesto para quien (como a mi) le apetezca saber más hay por ahí alguna referencia, "Some notes on lock-free and wait-free algorithms" de Ross Bencina y la entrada de la wikipedia inglesa Lock-free and wait-free algorithms

¿Estructuras de datos sin bloqueos? en Barrapunto

Memoria transaccional y concurrencia

En ACM Queue han publicado un articulo que ilustra bastante bien por donde irán los tiros (seguramente) en esto de la programación concurrente. Se trata de Unlocking Concurrency: Multicore programming with transactional memory y describe un poco que es la memoria transaccional y como se programaría en un lenguaje de los de uso cotidiano.

Básicamente se trata de especificar en el lenguaje que secuencias de operaciones forman una transacción de memoria, en la cual, como su nombre indica, o bien se realiza la operación completamente o bien es como si no se hubiese operado con ella, evitando la sincronización manual por parte del programador. Como se encargan de subrayar en el artículo tampoco es la panacea, pero ayuda(ría) mucho a la gestión de la concurrencia.

Sólo falta ahora que se implemente en lenguajes de uso común y deje de ser sólo objeto de investigación académica...

La misma entrada en BP