No creo que te interese, pero en Lecturas aleatorias [blogspot.com] dejo registro de los libros que voy leyendo...
Esta es toda mi información de usuario
Diseño elegante y sencillo frente a implementación correcta. No siempre están enfrentados, pero muchas veces si.
El tema me ha surgido leyendo un blog muy interesante, Thinking parallel, en el cual se discute si los mutex recursivos son buenos o no, que apunta a un excelente post en comp.programming.threads Recursive mutexes by David Butenhof. Las dos tesis contrapuestas son:
El problema más grande de todos los problemas de los mutex recursivos es que animan a perder la pista de tu esquema de bloqueos y su ámbito (scope). Esto es mortal. Nefasto. Es el "comedor de threads". Has de coger los mutex durante el tiempo más corto posible. Punto. Siempre. Si estás llamando a algo con un mutex cogido es porque no sabes si está cogido o porque no sabes si la llamada lo necesita, entonces lo estas cogiendo demasiado tiempo.
Abstrayendo... ¿Que caracteriza (entre otras cosas) un buen diseño?
Entre la sencillez del diseño y la optimización y corrección de la implementación es donde suele haber más problemillas. En lugar de rediseñar cuando se detectan errores de rendimiento el camino más fácil son los hacks , que cuando no son excelentes suelen embarullar el código y distorsionar el propósito del diseño.
En estos casos no habría que tener miedo de refactorizar el código y rediseñar si es preciso, aunque en un caso ideal habría que haberlo tenido en cuenta antes, como requisitos no funcionales, pero sin caer en la sobreingeniería. Difícil verdad
Se podría decir que los mutex recursivos son un hack y por ese motivo usarlos con mucha precaución. Como dice el propio Butenhof (extensible a todos los hacks)
Los mutex recursivos son un hack. No hay nada erróneo si se usan, pero son una muleta. ¿Tienes una pierna rota o una librería? Bueno, usa una muleta. Pero al menos sé consciente de que la estás usando y porqué.
Interesante
(Puntos:1)Gracias y sigue así!
Re:bueno,
(Puntos:2)No estoy de acuerdo. No es lo mismo un try catch que un sistema de control de concurrencia. El Mutex hace que todo el sistema tenga que esperar. Reduce la capacidad de la CPU de hacer otras cosas y aumenta la posibilidad de bloqueo. Un try no tiene un gran coste computacional. Si hay un excepción de entrada salida lo mejor es que incluya todas las operaciones durante la entrada salida.
Lo del ámbito de variables me parece razonable pero nada con lo que perdería demasiado tiempo.