Barrapunto

el ejemplo de la raíz cuadrada es muy malo: todo el mundo sabe como se calcula una potencia, y con saber que una raíz es el inverso, quedan pocas cosas más por saber.

Pero es que ese es el objetivo del ejemplo, hacer ver que la implementacion es irrelevante mientras el contrato del API se cumpla, y de ahi el usar algo que "todo el mundo sabe" pero que no todo el mundo conoce el algoritmo. Hay un monton de formas de calcular una raiz cuadrada, cada cual con sus ventajas e inconvenientes. No necesito conocer ninguno para calcular una raiz cuadrada.

¿Sabías que pasar un mutex de un procesador a otro implica mover una línea de caché (y marcar como exlusiva) de un procesador a otro, y que esto puede tardar 100 ciclos (y en cada microarquitectura se va incrementando el coste)?

Hablas de ciclos teoricos o de ciclos practicos? Porque no mencionas ninguna implementacion en concreto. Y volvemos a lo mismo. 100 ciclos a lo mejor es lo que debe consumir al menos el mutex, y quizas es lo que consuma la libreria estandar del lenguaje de turno para realizar esa operacion, pero si Fulano decide que es mas listo que nadie y se lo implementa el solito, quizas te sale que tarda 1000 ciclos. O peor, que no funciona como debe (y ponte a depurar concurrencia... diversion garantizada).

Ahora hablemos de SQL. ¿Qué nivel de aislamiento utilizas en tus bases de datos (uncommitted/read commited/repeatable read/isolated)? ¿Se utilizan cerrojos, MVCC, o una mezcla? ¿Te parece que SQL esconde toda la complejidad inherente a la programación concurrente?

Todo eso lo puedes encontrar en la documentacion de Postgres. Quizas aqui haya mucho rey del mambo que sepa mas de concurrencia que la gente que se ha currado Postgres, yo no. Pero se leer, y cuando leo que una operacion bloquea de forma exclusiva una tabla, no me hace falta implementar un motor de base de datos para saber cuando no debo usar dicha operacion.