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

Un vistazo al código de chrome

Una de los aspectos que más me ha interesado de chrome es su arquitectura, aquello de ejecutar un proceso por pestaña para dejar que el sistema operativo haga unos de los trabajos para los que está diseñado: aislar procesos independientes y gestionar la memoria. Entonces he decidido a echarle un vistazo al código, que para eso está ahí ;)

Lo primero que hay que decir es que el IPC se hace mediante pipes con nombre, como parece que debería ser, aunque sea una de esas características de los SO en decadencia, o por ser más preciso, menos de moda. El documento que describe el IPC en chromium es escueto así que he hecho una inmersión en el código, aunque superficial, sobre todo para encontrar detalles de implementación. Los mensajes se gestionan con una clase ChannelProxy (definida en src/chrome/common/ipc_channel_proxy.h) Las pipes se gestionan con la clase Channel (mismo directorio, icp_channel.h) Curiosamente está implementada llamando directamente a la API de win32, ella misma hace de capa de abstracción y de interfaz a implementar.

Otro aspecto que me llamaba mi curiosidad es la serialización de los mensajes y lo hacen especializando Read, Write y Log de ParamTraits (en src/chrome/common/ipc_message_utils.h) a la estructura o tipo de dato en concreto. La serialización los tipos de datos primitivos están en Pickle (src/base/pickle.cc), que es base de Message (src/chrome/common/ipc_message.cc)

Como uno de mis intereses es la multiplataforma he buscado como solucionaban la gestión de threads y procesos. Acerca de los threads se han creado un interfaz sencillo en src/base/platform_thread.h con dos implementaciones, platform_thread_win.cc y platform_thread_posix.cc. Cabe destacar el siguiente comentario de este último fichero:

The POSIX standard does not provide for naming threads, and neither Linux
nor Mac OS X (our two POSIX targets) provide any non-portable way of doing
it either. (Some BSDs provide pthread_set_name_np but that isn't much of a
consolation prize.)

Que creo que dice algo de su política y no se si gustará mucho a los BSDros... El buceo por la gestión de procesos ha sido un poco decepcionante porque sólo existe un process_util::LaunchApp que básicamente llama a un CreateProcess de nuevo de la API de win32. Seguramente han ido pensado previamente en los interfaces y solo están a falta de la implementación en distintas plataformas, pero da una sensación de trabajo a medias, quizás reflejo de un proyecto real (en contraposición de una prueba de concepto) saliendo de su fase temprana. Cabe preguntarse cuanto les costará implementar y testear esas funcionalidades... Ah, calla, que somos millones los betatesters.

(Actualización) Un tímido buceo en src/net/base me dice que el código de red es muy windowscéntrico, con muchas inclusiones de winsock2.h, incluso en cabeceras :/ aún les queda trabajillo por delante. Los interfaces de las clases parecen bien definidos y eso les ahorrará trabajo, pero es bien sabido que un interfaz no es válido y está maduro hasta que no funciona en todas la plataformas a las que se dirige...

Uhmmm, acabo de ver un enlace de donde se baja las fuentes que se suponen del desarrollo en linux. Seguiremos informando, pero ya sólo esta distinción de obtención de fuentes no da buena espina...

(Actualización2)Ya lo he bajado pero es básicamente el mismo código. Me debo estar perdiendo algo, porque sino está muy verde...

(Actualización3) Leo en kriptópolis que Chrome usa CSP en lugar de PKCS :O No hay rastro de ningún PKCS (11 por ejemplo, el que usa El DNIe) ni de NSS (la librería criptográfica de Netscape que usa firefox) Me temo que la portabilidad no se la han tomado en serio o quieren que se la hagan otros... Alucino.(fin actualizaciones).

Desde el punto de vista gráfico he visto que tiene muchas de dependencias de la WTL, lo que dice también poco de la portabilidad en primera instancia. Ya veremos a ver como solucionan ese temilla, aparentemente con lo que figura en src/base/gfx. No obstante hay pocos restos de WTL en los .h, así que quizás ya van bastante adelantados... Misma sensación de a medias.

Seguro que habría mucho más que decir, sobre todo del diseño e implementación de JavaScript, V8 pero creo que se escribirá de eso suficiente (ya se ha escrito mucho de su eficiencia, veremos cuanto hay de hype) y de temas relacionados como la ejecución de ruby sobre V8... Ains que bien se lo hace google ;)

La misma entrada y más comentarios en Un vistazo al código de chrome en barrapunto