En un proyecto MVC de ASP.NET tenemos varias instancias de datos que requieren una buena cantidad de recursos y tiempo para construir. Queremos cachearlos.

MemoryCache proporciona cierto nivel de seguridad de subprocesos, pero no lo suficiente para evitar ejecutar varias instancias de código de construcción en paralelo. Aquí hay un ejemplo:

<code>var data = cache["key"];
if(data == null)
{
  data = buildDataUsingGoodAmountOfResources();
  cache["key"] = data;
}
</code>

Como puede ver, en un sitio web ocupado, cientos de subprocesos podrían ir dentro de la sentencia if simultáneamente hasta que se construyan los datos y hacer que la operación de construcción sea aún más lenta, consumiendo innecesariamente los recursos del servidor.

Hay un atomicAddOrGetExisting implementación en MemoryCache pero incorrectamente requiere "valor para establecer" en lugar de "código para recuperar el valor para establecer", que creo que hace que el método dado sea casi completamente inútil.

Hemos estado utilizando nuestros propios andamios ad-hoc alrededor de MemoryCache para hacerlo bien, sin embargo, se requiere explícito.locks. Es incómodo utilizar objetos de bloqueo por entrada y, por lo general, salimos compartiendo objetos de bloqueo que están lejos de ser ideales. Eso me hizo pensar que las razones para evitar tal convención podrían ser intencionales.

Así que tengo dos preguntas:

¿Es una mejor práctica nolock ¿código de construcción? (Eso podría haber sido más sensible para uno, me pregunto)

¿Cuál es la forma correcta de lograr el bloqueo por entrada de MemoryCache para dicho bloqueo? El fuerte impulso de usarkey cadena como el objeto de bloqueo se descarta en ".NET Locking 101".