Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

mig21 (7781)

mig21
  reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw

Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames ;)

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 :)

Down Kill Up Publicidad

Bitácora de mig21 (7781)

Martes, 03 de Octubre 2006

Diseño sencillo contra implementación correcta

09:55h.
Tecnología

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:

  • Los mutex recursivos son buenos, porque ayudan a modularizar y a abstraer (diseño elegante y sencillo)
  • Los mutex recursivos son malos: Del post de Butenhof:"Un diseño correcto y bien pensado no requiere mutex recursivos" (implementación que puede ser no correcta)
Lo cierto es que la tesis de Butenhof está muy bien argumentada y nos da pistas de cuando estamos haciendo las cosas mal:

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?

  • No se repiten conceptos (fácilmente modificable)
  • Es elegante (desde lejos, desde arriba, a nivel de relación entre objetos, módulos ...)
  • Es sencillo (en lo posible, para no complicar o entorpecer la implementación)
¿Que caracteriza (entre otras cosas) una buena implementación?
  • No se repite código (mantenible)
  • Es elegante (el código, de cerca, a nivel de función)
  • Es correcto
  • Es óptimo

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é.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Interesante

    (Puntos:1)
    por pobrecito hablador el Martes, 03 Octubre de 2006, 11:03h (#822222)
    Sí, ya sé que no aporto nada, pero tu post me ha parecido de lo más interesante por aquí. Tanta política ya cansa ;-D

    Gracias y sigue así!
  • Re:bueno,

    (Puntos:2)
    por aquelquesiente (20546) el Martes, 03 Octubre de 2006, 14:36h (#822325)
    Es que la regla de hacer un mutex lo mas pequeño posible se aplica a un monton de cosas semejantes.

    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.
    [ Padre ]
  • 1 respuesta por debajo de tu umbral de lectura actual.