Diseño de una clase Thread Safe

Question

Al leer la documentación de MSDN, siempre le permite saber si una clase es segura para subprocesos o no. Mi pregunta es ¿cómo se diseña una clase para que sea segura? No estoy hablando de llamar a la clase con el bloqueo. Quiero decir que estoy trabajando para Microsoft, creo XXX class \ object y quiero decir que es "Thread Safe" ¿qué debo hacer?

Answer 1

La manera más fácil y más infalible de hacer que un hilo de clase sea seguro es hacerlo immutable. La belleza de esto es que nunca tendrás que molestarte en volver a bloquear.

Receta: Hacer todas las variables de instancia readonly en C# (final en Java).

• Un objeto inmutable, una vez creado e inicializado en el constructor, no puede cambiar.
• Un objeto inmutable es seguro para subprocesos. Período.
• Esto no es lo mismo que tener una clase con solo constantes.
• Para partes mutables de su sistema, aún necesita tener en cuenta y manejar las propiedades de bloqueo/sincronización. Esta es una de las razones para escribir clases inmutables en primer lugar.

Consulte este question también.

Answer 2

Para indicar que la clase es segura para subprocesos, está confirmando que las estructuras de datos internas de la clase no se dañarán mediante el acceso simultáneo de varios subprocesos. Para hacer esa afirmación, necesitaría introducir el bloqueo (sincronización en Java) alrededor de las secciones críticas del código dentro de la clase, lo que potencialmente podría conducir a la corrupción de que fueran ejecutadas por múltiples hilos concurrentes.

Answer 3

Las clases no genéricas ICollection proporcionan propiedades para la seguridad del hilo. IsSynchronized y SyncRoot. desafortunadamente no puedes configurar IsSynchronized. Puede leer más sobre ellos here

En sus clases puede tener algo similar a IsSynchronized y Syncroot, exponer los métodos/propiedades públicos solo y el método interno de verificación del cuerpo para ellos. Su IsSynchronized será una propiedad de sólo lectura, por lo que una vez que se ha inicializado la instancia, usted no será capaz de modificarlo

bool synchronized = true; 
var collection = new MyCustomCollection(synchronized); 
var results = collection.DoSomething(); 

public class MyCustomCollection 
{ 
    public readonly bool IsSynchronized; 
    public MyCustomCollection(bool synchronized) 
    { 
    IsSynchronized = synchronized 
    } 

    public ICollection DoSomething() 
    { 
    //am wondering if there is a better way to do it without using if/else 
    if(IsSynchronized) 
    { 
    lock(SyncRoot) 
    { 
     MyPrivateMethodToDoSomething(); 
    } 
    } 
    else 
    { 
     MyPrivateMethodToDoSomething(); 
    } 

    } 
} 

Puede leer más acerca de cómo escribir colecciones seguras hilo en Jared Parson's blog

Answer 4

La documentación no hace sugieren que las clases son seguras para hilos, solo los métodos lo son. Para afirmar que un método es seguro para subprocesos, tiene que ser invocado desde múltiples subprocesos simultáneamente sin dar resultados incorrectos (donde los resultados incorrectos serían el método devolviendo el valor incorrecto o el objeto entrando en un estado inválido).

Cuando la documentación dice

estáticos públicos (Shared en Visual Basic) de este tipo son el hilo seguro.

probablemente significa que los miembros estáticos de la clase no cambian el estado compartido.

Cuando la documentación dice

los miembros de instancias están garantizados para la ejecución de subprocesos.

probablemente significa que los métodos tienen un bloqueo interno mínimo.

Cuando la documentación dice

Todos los miembros públicos y protegidos de esta clase son hilos de proceso seguro y puede ser utilizado simultáneamente desde múltiples hilos .

probablemente significa que todos los métodos que puede llamar utilizan el bloqueo apropiado dentro de ellos. También es posible que los métodos no muten ningún estado compartido, o que sea una estructura de datos sin bloqueo que el diseño permite el uso simultáneo sin bloqueos.

Answer 5

Las clases de seguridad de subprocesos se trata de proteger los datos (variables de instancia) en su clase. La forma más común de hacerlo es usar la palabra clave . El error de novato más común es el uso de bloquear toda la clase en lugar de un bloqueo de más de grano fino:

lock (this) 
{ 
    //do somethnig 
} 

El problema con esto es que se le puede dar un rendimiento importante si la clase hace algo importante. La regla general es bloquear lo menos posible en el menor tiempo posible.

Puede leer más aquí: lock keyword in C#

Cuando haya strarted para entender más profundamente multithreadnig también se puede echar un vistazo a ReaderWriterLoch y semáforo. Pero sugiero que solo comiences con la palabra clave de bloqueo.

Answer 6

Además de las otras excelentes respuestas aquí, considere otro ángulo también.

No es suficiente que la estructura de datos interna de la clase sea 100% segura para subprocesos si la API pública tiene operaciones de varios pasos que no se pueden usar de forma segura para subprocesos.

Considere una clase de lista que ha sido construida de tal forma que no importa cuántos hilos estén haciendo sin importar cuántos tipos de operaciones contenga, la estructura de datos interna de la lista siempre será consistente y correcta.

consideran este código:

if (list.Count > 0) 
{ 
    var item = list[0]; 
} 

El problema aquí es que entre la lectura de la propiedad Count y la lectura del primer elemento a través de la [0] indexador, otro hilo podría haber limpiado el contenido de la lista .

Este tipo de seguridad de subprocesos generalmente se olvida cuando se crea la API pública. Aquí, la única solución es que el código de llamada bloquee manualmente algo en cada tipo de acceso para evitar que el código se cuelgue.

Una manera de resolver esto sería para el autor tipo de lista para considerar escenarios de uso típicos y añadir los métodos apropiados para el tipo:

public bool TryGetFirstElement(out T element) 

entonces tendría que:

T element; 
if (list.TryGetFirstElement(out element)) 
{ 
    .... 

presumiblemente , TryGetFirstElement funciona de manera segura para hilos y nunca devolverá true al mismo tiempo, ya que no puede leer el primer valor del elemento.