Double-Checking Locking,volatile y demás ‘cool’ codes

Hoy por la tarde comiendo con mi compañero Rodrigo, estuvimos hablando, como no, de diversos trozos de código que vemos implementados y diversas recomendaciones que podemos ver y releer por todo esta gran enciclopedia que son los buscadores de internet. Una de las cosillas graciosas de las que hablamos es de los códigos ‘cool’ que se suelen ver en implementaciones y en las citadas enciclopedias. Para muestra un ejemplo:

 

using System;

 

public sealed class Singleton

{

private static volatile Singleton instance;

private static object syncRoot = new Object();

 

private Singleton() {}

 

public static Singleton Instance

{

get

{

if (instance == null)

{

lock (syncRoot)

{

if (instance == null)

instance = new Singleton();

}

}

return instance;

}

}

}

 

Cool ¿verdad? Así de primeras diríamos, esto lo ha hecho un ‘programador serio serio’, más si cabe si este código lo podemos ver como ejemplo en ‘Patterns and Practices’ para patrones singleton seguros en multiproceso. Vemos además un ‘keyword’ de estos que son desconocidos por la gran mayoría, en concreto ‘volatile’ ¿Cuántos conocéis para qué sirve?. El caso es que este patrón implementa lo que se conoce como ‘Double-Checked Locking Tecnique’ y que efectivamente resuelve los propósitos de esta implementación en otros lenguajes como C++ o Java… pero….. ¿realmente necesitamos esto o como parece más ‘cool’ lo implementamos?

Veamos otra alternativa:

 

public sealed class Singleton

{

private static readonly Singleton instance = new Singleton();

 

private Singleton(){}

 

public static Singleton Instance

{

get

{

return instance;

}

}

}

En la mayoría de los casos esta implementación ofrece la misma funcionalidad y es mejor en cuanto a rendimiento ya que evita que se tenga que programar un bloqueo . Si, es menos ‘cool’ pero funciona igual de bien en escenarios de multiproceso puesto que el CLR siempre te asegura que las llamadas al constructor de tu singleton estático son ‘thread safe’. El ‘Double Checked Locking’ tiene sentido cuando la inicialización del miembro estático requiera además iniciar algunos de los miembros de la misma y por lo tanto no podamos recurrir a la simple llamada al constructor del miembro estático y deberíamos evitarlo excepto en estos casos.

Saludos

Unai Zorrilla Castro

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *