Bloquear en un objeto

Question

A menudo veo código como el que es shown here, es decir, donde se asigna un objeto y luego se utiliza como un "objeto de bloqueo".

Me parece que puede usar cualquier objeto para esto, incluido el evento en sí mismo como el objeto de bloqueo. ¿Por qué asignar un nuevo objeto que no hace nada? Según entiendo, llamar a lock() en un objeto no altera realmente el objeto en sí mismo, ni bloquea su uso, simplemente se utiliza como marcador de posición para el anclaje de múltiples instrucciones de bloqueo.

public class Shape : IDrawingObject, IShape 
{ 
    // Create an event for each interface event 
    event EventHandler PreDrawEvent; 
    event EventHandler PostDrawEvent; 

    object objectLock = new Object(); 

    // Explicit interface implementation required. 
    // Associate IDrawingObject's event with 
    // PreDrawEvent 
    event EventHandler IDrawingObject.OnDraw 
    { 
     add 
     { 
      lock (objectLock) 
      { 
       PreDrawEvent += value; 
      } 
     } 
     remove 
     { 
      lock (objectLock) 
      { 
       PreDrawEvent -= value; 
      } 
     } 
    } 
} 

Así que mi pregunta es, ¿es realmente una buena cosa que hacer?

Answer 1

incluyendo el evento en sí

No, usted no puede hacer eso. Un "evento" es en realidad solo algunos métodos de acceso. Suponiendo que se refiera al delegado de respaldo, eso sería muy malo: los delegados son inmutables: cada vez que agrega/elimina un suscriptor, obtiene un delegado diferente.

En realidad, el compilador 4.0 ahora hace esto con código de bloqueo usando Interlocked - puede valer la pena seguir este enfoque.

En el ejemplo, el objectLock asegura que todas las personas que llaman (a esa instancia) están encerrando en contra de la misma objeto, que es importante - pero sin la fealdad de bloqueo en this (que es como el compilador de C# utiliza trabajar).

-

Actualización: el ejemplo muestra el código que es necesario antes de C# 4.0, el acceso a un campo como el evento dentro el tipo habló directamente al campo: el campo-como-evento normal de bloqueo no fue respetado Esto fue cambiado en C# 4.0; ahora se puede (en C# 4.0) segura re-escribir esto como:

public class Shape : IDrawingObject, IShape 
{ 
    // Create an event for each interface event 
    event EventHandler PreDrawEvent; 
    event EventHandler PostDrawEvent; 

    event EventHandler IDrawingObject.OnDraw 
    { 
     add { PreDrawEvent += value; } 
     remove { PreDrawEvent -= value; } 
    } 
} 

es seguido Todo el comportamiento correcto.

Answer 2

Se recomienda bloquear en un campo estático privado, ya que esto garantiza que se bloquearán varios subprocesos que intenten acceder al bloqueo en paralelo. Bloquear en la instancia de la clase misma (lock(this)) o algún campo de instancia podría ser problemático porque si dos hilos llaman al método en dos instancias diferentes del objeto, podrán ingresar simultáneamente la instrucción de bloqueo.

Answer 3

Cualquier miembro del tipo de referencia privada hará el trabajo. Siempre que sea privado y nunca sea reasignado. Que noquea a un objeto delegado fuera de la ejecución, usted definitivamente no quiere ver que un bloqueo no haga su trabajo simplemente porque el código del cliente que no controla asigna un controlador de eventos. Extremadamente difícil de depurar.

El uso de miembros privados que realizan otro trabajo no es algo que se adapte bien. Si descubres que necesitas bloquear otra región de código mientras refactorizas o depuras, necesitarás encontrar otro miembro privado. Que es donde las cosas se pueden agriar rápidamente: puede elegir mismo miembro privado de nuevo. Deadlock llamando a la puerta.

Esto no ocurre si dedica un objeto de bloqueo a un conjunto específico de variables compartidas que deben protegerse. Te permite darle un buen nombre también.