Barrapunto

Quitando que no sé que tiene que ver conocer el error de redondeo que produce una función con la precisión, 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.

Un ejemplo algo mejor, aunque tampoco demasiado bueno, es un mutex. ¿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)?

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?

Por cierto, el error de redondeo se mide en ulps, unidad independiente de la precisión.

Y otras preguntas sobre SQL: ¿qué cerrojos utiliza tu BBDD: a nivel de fila, rango, página, tabla? ¿Los adquiere en dos fases, primero marcando el intento, y después adquiriéndolos? ¿Cómo se convierten los cerrojos compartidos (de lectura) en exclusivos (de escritura)? ¿Cómo afecta todo eso a las situaciones en las que se puede producir un interbloqueo entre transacciones? ¿Cómo reacciona tu BBDD a interbloqueos, qué transacción decide abortar?

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.