[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.
Una ración de enlaces relacionados con la programación concurrente:
Varios sobre concurrencia: JVM, clasificaciones y consejos en barrapunto
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...
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:
(Se habló en barrapunto de él hace bastante tiempo en Otro lenguaje de programación: Erlang)
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
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...
