threads - thread c#
lock(new object())-Culto a la carga o algĂșn "caso especial de lenguaje" loco? (3)
Estoy revisando un código escrito por un consultor, y aunque ya han aparecido docenas de banderas rojas, no puedo entender el siguiente fragmento:
private void foo()
{
if (InvokeRequired)
{
lock (new object())
{
if (m_bar!= null)
Invoke(new fooDelegate(foo), new object[] { });
}
}
else
{
if(OnBazChanged != null)
OnBazChanged();
}
}
¿Qué está haciendo lock (new object ()) aquí? No debería tener ningún efecto ya que siempre está bloqueado en otro objeto, pero este tipo de bloqueo es persistente en todo el código, incluso en partes que no son de copia y pegado. ¿Es este un caso especial en el lenguaje C # que se compila en algo que desconozco, o el programador simplemente adoptó algún culto a la carga que funcionó hace algún tiempo?
No me sorprendería si fuera alguien que vio esto:
private readonly object lockObj = new object();
private void MyMethod()
{
lock(lockObj)
{
// do amazing stuff, so amazing it can only run once at a time
// e.g. comands on the Mars Rover, or programs on iOS pre 4 / 5 ??
}
}
y pensó que podría cortar el número de líneas.
Sin embargo, estaría muy preocupado si ese fuera el caso ...
Probablemente sea inútil. Pero existe la posibilidad de que esté ahí para crear una barrera de memoria. No estoy seguro si c # bloquea la elisión o si lo hace si conserva la semántica de ordenamiento del bloqueo.
Here hay una pregunta similar y respuesta:
Los bloqueos garantizan la exclusión mutua: no más de un hilo puede mantener el bloqueo al mismo tiempo. El bloqueo se identifica con una instancia de objeto específica. Está creando un nuevo objeto para bloquearlo cada vez y no tiene forma de informar a ningún otro hilo para que se bloquee en la misma instancia de objeto exacta. Por lo tanto, su bloqueo es inútil.