Alcance de cerradura en C#: ¿el objeto devuelto sigue "bloqueado"?

Question

Suponiendo Tengo un objeto A que contiene

// ... 

private List<double> someList = new List<double>(); 

// ... 

public List<double> SomeList 
{ 
    get { lock (this) { return someList; } } 
} 

// ... 

sería hilo de seguridad para realizar la operación en la lista como en el código siguiente. Sabiendo que varias operaciones podrían ejecutarse simultáneamente por diferentes hilos.

A.SomeList.Add(2.0); 

o

A.SomeList.RemoveAt(0); 

En otras palabras, cuando se libera el bloqueo?

Answer 1

El bloqueo que se muestra en la pregunta no es de mucha utilidad.

Para hacer que las operaciones de la lista sean seguras, debe implementar sus propios métodos Agregar/Quitar/etc para ajustar los de la lista.

public void Add(double item) 
{ 
    lock(_list) 
    { 
     _list.Add(item); 
    } 
} 

Además, es una buena idea esconder la lista de los consumidores de su clase, es decir, hacer el campo privado.

Answer 2

No hay seguridad de subprocesos aquí.

El lock se libera tan pronto como el bloque que protege termina, justo antes de que la propiedad regrese, por lo que las llamadas a Add ad RemoveAt no están protegidas por el bloqueo.

Answer 3

El bloqueo se libera cuando el código dentro del bloqueo se termina de ejecutar. Además, bloquear esto solo afectará a la instancia actual del objeto

Answer 4

El bloqueo se libera cuando sale del cuerpo de la instrucción lock. Eso significa que su código es no a prueba de hilos.

En otras palabras, puede estar seguro de que dos subprocesos no se ejecutarán return someList en el mismo objeto al mismo tiempo. Pero ciertamente es posible que un subproceso ejecute Add() al mismo tiempo que otro subproceso ejecutará RemoveAt(), que es lo que lo hace no seguro para subprocesos.

Answer 5

Ok, solo por el placer de hacerlo.
Hay una manera de hacer que su objeto sea seguro para los hilos, usando arquitecturas que ya son seguras para la rosca.

Por ejemplo, puede hacer que su objeto sea un objeto de rosca simple COM. El objeto COM será seguro para subprocesos, pero pagará con rendimiento (el precio de ser flojo y no administrar sus propios bloqueos).

Create a COM Object in C#

Answer 6

... otros dijeron ya, pero sólo para formalizar un problema un poco ...

• En primer lugar, sugiere una lock (this) {...} 'alcance' - por ejemplo, como using(){} - solo se bloquea (esto en este caso) para variables dentro.Y eso es 'bueno' :) en realidad, como si no pudieras confiar en que todo el concepto de bloqueos/sincronización sería inútil,
• lock (this) { return something; } es un tipo de oxímoron - está devolviendo algo que desbloquea el en el mismo momento en que regresa,
• Y los problemas que creo que es la comprensión de cómo funciona. 'lock()' no está 'persistente' en un estado del objeto, por lo que puede devolver, etc. Mire aquí cómo está implementado How does lock work exactly? - la respuesta lo explica. Es más una 'sección crítica', es decir, usted protege ciertas partes del 'código', que usa la variable, no la variable misma. Cualquier tipo de sincronización requiere 'objetos de sincronización' para mantener los bloqueos, y para eliminarlos una vez que ya no se necesita el bloqueo. Echar un vistazo a este post https://stackoverflow.com/a/251668/417747, Esteban formulado que muy bien,

"Por último, existe la idea errónea de que bloquee (este) en realidad modifica el objeto pasado como parámetro, y de alguna manera hace es de sólo lectura o inaccesible. esto es falso. El objeto pasado como parámetro para bloquear simplemente sirve como una clave" (esto es una cita)

• que o bien (por lo general) Lock 'código privado' de un método de clase, propiedad ... - para sincronizar el acceso a algo lo estás haciendo por dentro, y accedes a un miembro privado (otra vez por lo general) para que nadie más pueda acceder sin su código sincronizado.
• O bien, crea una 'estructura' segura para hilos, como una lista, que ya está 'sincronizada' dentro para que pueda acceder a ella de manera segura para hilos. Pero no existen tales cosas (o no se usan, casi nunca) como cerraduras de paso o tener un lugar que bloquea la variable, mientras que la otra parte del código lo desbloquea, etc. (en ese caso es un tipo de EventWaitHandle que está más bien acostumbrado a sincronizar las cosas entre medias código 'distante' donde se dispara en otro, etc.)
• en su caso, la elección es que creo que ir con la 'estructura sincronizada', es decir, la lista que maneja internamente,