Antología del Disparate - II

Advertencia: Cualquier parecido con
la realidad, es sólo una sospechosa coincidencia...

stamos otra vez en una aplicación que maneja un buen puñado de hilos. El "genio" que la programa ya ha tomado consciencia de los peligros de la falta de sincronización, y dedica su tiempo libre a repartir bloqueos a diestra y siniestra. Este es un bello ejemplo de cómo se las gasta el caballerete (imaginario, of course):

private bool flag;
 
public void YoQueSe()
{
    if (Monitor.TryEnter(flag))
    {
        // Código "sincronizado" ...
        Monitor.Exit(flag);
    }
}

¿Puede ver los disparates? Son varios, por supuesto. ¿Cómo cree que se manifestó el problema? ¿Se atreve a imaginar cómo se le pudo haber ocurrido esta barbaridad a su perpetrador?

---

Esta es, amigo mío, la declaración del método TryEnter de la clase Monitor:

public static bool TryEnter(object obj);

Como puede ver, el parámetro del método debe ser un Object, o más exactamente, una referencia a un objeto. Como Object es la clase base final del CLR, cualquier cosa que pasemos como parámetro servirá, a efectos del sistema de tipos. El método incluso admite que pasemos un valor de tipo Boolean...

... con la única pega de que Boolean es una estructura, un tipo con semántica de asignación por valor. Para poder pasar un Boolean donde se espera un objeto, .NET aplica la operación llamada boxing al valor. Es decir, crea un objeto temporal del tamaño adecuado, y copia en su interior el valor que queríamos pasar. ¿No queríamos una referencia? Tras el boxing ya tenemos una.

¿Y qué hay con la llamada final a Exit? Este es el prototipo de este segundo método:

public static void Exit(object obj);

Nuevamente, nos piden un objeto. Y el compilador no protesta si pasamos un valor de tipo Boolean. Simplemente mete el valor en una "cajita" y pasa el puntero a ésta. ¿La pena? Pues que las llamadas a TryEnter y Exit deberían utilizar el mismo objeto... y cada vez que se realiza el boxing, ¡se crea una instancia temporal diferente!

¿Qué consecuencias cree que tenía el disparate? Sorprendentemente, ¡ninguna!... al menos, mientras la aplicación se mantuvo ejecutando sobre .NET v1.1. Fue al migrar a .NET 3.5 que estos errores empezaron a ser detectados en tiempo de depuración. La llamada a Exit comenzó a generar una excepción, advirtiendo que se intentaba desbloquear a través de un objeto no bloqueado. Claro, sería una estupidez que el CLR tuviese que verificar en cada llamada a Exit que el objeto pasado no sea una instancia creada por boxing: penalizaría a los buenos programadores para evitar que los peores metiesen la pata.

¿Se da cuenta de que, ni siquiera en .NET v1.1, la aplicación estaba protegiendo la sección de código de marras? Si en algún momento se produjeron errores de sincronización en dicha sección, o fueron ignorados... o se perdieron gracias a la demencial política de manejos de excepciones de mi aplicación imaginaria. Observe que hay un segundo error en el código mostrado: se supone que las llamadas a TryEnter y Exit deberían estar asociadas a una instrucción try/finally.

Y ahora viene lo mejor: ¿cómo imagina que se le ocurrió la burrada al genio? El uso de TryEnter nos permite reconstruir los hechos. En realidad, el aprendiz de brujo intentó usar la instrucción lock en primer lugar. ¡Pero lock sí que puede detectar cuando alguien le pasa una estructura en vez de una referencia! Y como lock no se dejaba violentar, el muy pillo tradujo el código que suponía que se generaba para dicha instrucción. Pero como manazas que es, incluso eso lo hizo mal...

Moraleja: odio repetirme pero, por favor, esos genios que deambulan por ahí, ¡RTFM!