Memoria transaccional ¿Sólo un juguete para investigadores?

En Software Transactional Memory: why is it only a research toy? de Calin Cascaval et al. se repasan algunas de las razones por las que, tras unos años de investigación, la memoria transaccional no ha dado el salto para ser usada en otros entornos. Se nombran sobre todo razones de rendimiento, de usabilidad (semántica confusa) y de interacción con sistemas que no la usan. No obstante no todo el mundo se da por vencido y por ejemplo Larry O'Brien escribe en Cascaval et al.'s skepticism on transaction memory una visión un poco más optimista indicando que aún queda espacio para la investigación y la optimización. ¿Acabaremos usando STM o morirá antes de nacer?

La misma entrada y más comentarios en Memoria transaccional ¿Sólo un juguete para investigadores? en barrapunto

Varios sobre concurrencia y el rol de los 'arquitectos'

Comenzando por el minipost de Miguel de Icaza en el que habla de programación paralela y siguiendo enlaces:

• Design Considerations For Parallel Programming de David Callahan
• Solving 11 Likely Problems In Your Multithreaded Code de Joe Duffy
• Repasando el blog de este último también apunta a .NET Matters: False Sharing
• Y también del blog de Joe Duffy, y aunque no es sobre concurrencia y probablemente sean obviedades, me ha gustado A few thoughts on the role of software architects

La misma entrada y más comentarios en Varios sobre concurrencia y el rol de los 'arquitectos' en barrapunto

Reescribiendo una cola sin bloqueos

Herb Sutter se quejó en Lock-Free Code: A False Sense of Security(*) de lo difícil que es escribir código sin bloqueos incluso para expertos y lo hizo poniendo un ejemplo de una implementación errónea de una cola. Ahora ha retomado el tema para demostrar como sería una implementación correcta en Writing Lock-Free Code: A Corrected Queue.

(*) Hablamos de este artículo en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM


La misma entrada y más comentarios en Reescribiendo una cola sin bloqueos en barrapunto

¿Cómo funcionan los cierres de exclusión mutua?

Vía reddit veo un artículo muy didáctico de como funcionan internamente los cierres de exclusión mutua que usamos diariamente y así hacernos a la idea de lo que hay debajo.

La misma entrada y más comentarios en ¿Cómo funcionan los cierres de exclusión mutua? en barrapunto

"Patrones en programación paralela" por Ralph Johnson

Ralph Johnson, coautor del conocidísimo Design Patterns dió una charla sobre patrones en programación paralela: Parallel Programming Patterns, que está disponible online en un flash con las transparencias integradas para un mejor seguimiento. [Vía Sutter's Mill]


La misma entrada y más comentarios en "Patrones en programación paralela" por Ralph Johnson en barrapunto

Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM

Ración de varios sobre concurrencia:

• "Lock-Free Code: A False Sense of Security" de Herb Sutter que viene a decir algo que por aquí intuíamos:

  [Lock-free code is] hard even for experts. It’s easy to write lock-free code that appears to work, but it’s very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction.

  es decir, entre otras cosas, recordar ser humildes.
• Si aún siendo humildes queremos saber más sobre estos temas podemos echarle un vistazo a "Just What-the-Heck is a 'wait-free' algorithm?" de Cliff Click en el que repasa este tipo de algoritmos que según los que saben de ésto aún son más difíciles de codificar que los 'lock-free' (son un subconjunto de ellos no obstante)
• The Java Memory Model in 500 Words Un breve resumen, casi chuleta, del modelo de memoria en Java.
• Si lo que nos interesa son más las implementaciones que las especificaciones podemos echar un vistazo a The Hotspot Java Virtual Machine, una completa presentación con detalles de implementación de dicha máquina virtual. Repasa compilación, sincronización, recolección de basura y posibles direcciones de investigación.

La misma entrada y más comentarios en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM 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

Varios sobre concurrencia y patrones de diseño

Ración de enlaces:

• The Pillars of Concurrency por Herb Sutter Un resumen de los distintos escenarios en lo que se debe aplicar la concurrencia y de las posibles soluciones presentes y futuras. Comentado en LtU, The Pillars of Concurrency
• Un par de vídeos (que aún no he visto, pero que tienen muy buena pinta): C++ Threads por Lawrence Crowl y Concurrency/message passing Newsqueak por Rob Pike (En la tendencia de que los materiales se cuelguen más "en bruto", vídeos y entrevistas en audio y video en lugar de transcritos... más fácil de hacer pero peor para buscar algo concreto y al ser en lenguaje oral es posible que peor para los no nativos. Aunque estos parece que con las diapositivas se pueden seguir bien...)
• Un par de enlaces para reflexionar acerca de los patrones de diseño: Rethinking Design Patterns de Jeff Atwood, que viene a recordar los argumentos que se citaron por aquí en Enlaces varios (IV), que los patrones de diseño son síntomas de defectos en los lenguajes de programación. También Patterns I Hate #2: Template Method, que parece ser una serie en la que se medita sobre lo que se gana y se pierde con algunos patones.

Varios sobre concurrencia y patrones de diseño en barrapunto

Programando con Erlang

Dave Thomas ha escrito una serie de apuntes introductorios a erlang, aprovechando el nuevo libro, Programming Erlang de Joe Armstrong (un esfuerzo publicitario, porque el libro se publica bajo el amparo de los programadores pragmáticos, pero aquí nos da igual, ¿no?)

Entonces pasemos a los enlaces:

• A First Erlang Program Un programita para usar la API de servicios web de amazon
• Adding Concurrency to Our Erlang Program El mismo programa, pero concurrente

Y algunos enlaces más

• What's all this fuss about Erlang?
  por Joe Armstrong, una introducción al lenguaje
• Concurrent Programming in Erlang, Part I (pdf 884 KB) un libro introductorio con el que estuve trasteando hace un tiempo, también de Armstrong (entre otros)

Publicitado también desde los programadores pragmáticos... ¿le pasará lo mismo que a Ruby? ¿tendrá el mismo crecimiento? Personalmente lo dudo, a pesar de que el lenguaje tiene unas características muy interesantes, entre otras el tratamiento de la concurrencia. La principal pega la comenta el propio Armstrong en el artículo introductorio: ¿Es Erlang difícil? No, pero es diferente.

(Se habló en barrapunto de él hace bastante tiempo en Otro lenguaje de programación: Erlang)

Programando con Erlang en barrapunto