¿Cómo diseñar estructuras de datos concurrentes?

Anteriormente hice esta pregunta en Programmers.SE , sin éxito.

Estoy buscando recursos de aprendizaje por escrito sobre cómo diseñar estructuras de datos concurrentes. Estoy más interesado en el proceso de diseño (por ejemplo, identificar los invariantes correctos) que en el producto final (una lista completa de códigos).

Para un ejemplo concreto: Realmente disfruté el libro de Chris Okasaki "Estructuras de datos puramente funcionales", porque es más que una referencia: guía al lector a través del diseño de sus estructuras de datos y algoritmos. A menudo, el libro motiva un diseño complicado o no obvio al dar primero una versión más ingenua, y solo luego refinarlo hasta lograr la complejidad de tiempo deseada (ya sea en el peor de los casos o amortizada). Este es el tipo de cosas que estoy buscando.

Entonces:

1. ¿Qué técnicas o heurísticas existen para diseñar estructuras de datos concurrentes?

2. ¿Hay libros, documentos, publicaciones de blog, tutoriales, etc. que expliquen estas técnicas y heurísticas?

Si bien no he leído profundamente en esta área, descubrí que The Art of Multiprocessor Programming de Maurice Herlihy y Nir Shavit son una introducción y un estudio útil de las técnicas. Explora diferentes algoritmos, razones sobre cómo funcionan y examina las compensaciones, características y limitaciones de los diferentes enfoques. Si bien tiene cierto formalismo, espero que sea un texto bastante introductorio y accesible.

Para una muestra del texto, aquí está la introducción a la sección sobre Registros atómicos de la edición de 2008:

El lugar obvio para comenzar es preguntar si podemos resolver el consenso utilizando registros atómicos. Sorprendentemente, tal vez, la respuesta es no. Mostraremos que no hay un protocolo de consenso binario para dos hilos. Lo dejamos como un ejercicio para mostrar que si dos hilos no pueden llegar a un consenso sobre dos valores, entonces los nhilos no pueden llegar a un consenso sobre los kvalores, dónde n > 2y k > 2.

La respuesta no es tan simple como la programación funcional. En la programación funcional aquí tenemos un concepto general de lo que es la programación funcional y la especificación de las estructuras de datos en sí no cambia por el hecho de que son funcionales. Sin embargo, ese no es el caso con la concurrencia:

1. Hay muchos modelos de computación distribuida / paralela / concurrente.

2. No existe una transformación general que, dada la especificación de una estructura de datos secuencial, le proporcione la especificación de su versión concurrente. Hay varias condiciones (generalmente se clasifican en virtud de la seguridad y LIVENESS condiciones) que podemos requerir de una versión concurrente de una estructura de datos, hay varios nuevos resultados (por ejemplo, operaciones de pausa, operaciones abortan, choques, etc.). Por lo tanto, puede haber muchas especificaciones diferentes para versiones concurrentes de una estructura de datos secuencial.

Algunas preguntas sobre referencias en informática distribuida:

• ¿Comenzar a aprender sobre la teoría de los sistemas distribuidos?
• Libro moderno de computación distribuida
• Libros: Computación Distribuida

Vea también ¿Por qué no hemos podido desarrollar una teoría de complejidad unificada de la computación distribuida?

La primera regla de las estructuras de datos concurrentes es: no desea concurrencia.

En el caso ideal, la computación distribuida / paralela / concurrente significa que tiene una serie de procesos secuenciales completamente independientes. Cada proceso tiene sus propios datos y recursos, y el proceso ni siquiera conoce otros procesos.

En el peor de los casos, tiene un sistema de memoria compartida con múltiples hilos que consultan y actualizan las mismas estructuras de datos simultáneamente. Probablemente algo ha salido terriblemente mal, si lo estás considerando seriamente.

Por supuesto, cuando hablamos de estructuras de datos concurrentes, es inevitable cierto grado de concurrencia. Todavía queremos minimizarlo. Cuanto más tiempo pueda funcionar un proceso secuencialmente sin tocar mutexes, realizar operaciones atómicas o pasar mensajes, es más probable que todo funcione correctamente y el rendimiento sea aceptable.

Las estructuras de datos estáticos con actualizaciones por lotes requieren menos sincronización que las estructuras de datos dinámicas. Debe intentar que sus estructuras de datos concurrentes sean estáticas, o al menos lo más cercanas posible a la estática. Si su algoritmo requiere consultas entrelazadas con actualizaciones, intente cambiar el algoritmo antes de recurrir a estructuras dinámicas compartidas.

El mismo principio de diseño también se aplica a la actualización de estructuras de datos estáticos. Cuanto más independiente sea el proceso de actualización de la estructura, mejor funcionará todo.