ReaderWriterLock vs lock {}

Question

Explique cuáles son las principales diferencias y cuándo debería usar qué.
El enfoque en las aplicaciones web multihilo.

Answer 1

lock permite que solo un hilo ejecute el código al mismo tiempo. ReaderWriterLock puede permitir que varios subprocesos se lean al mismo tiempo o que tengan acceso exclusivo para escritura, por lo que puede ser más eficiente. Si está usando .NET 3.5 ReaderWriterLockSlim es aún más rápido. Por lo tanto, si su recurso compartido se lee con más frecuencia que el que se escribe, use ReaderWriterLockSlim. Un buen ejemplo para usarlo es un archivo que lee con mucha frecuencia (en cada solicitud) y rara vez actualiza el contenido del archivo. Por lo tanto, cuando lee un archivo, ingresa un bloqueo de lectura para que muchas solicitudes puedan abrirlo y, cuando decida escribirlo, ingrese un bloqueo de escritura. Usar un lock en el archivo significará básicamente que puede atender una solicitud a la vez.

Answer 2

considerar el uso de ReaderWriterLock si usted tiene un montón de hilos que sólo necesitan para leer los datos y estos hilos están siendo bloqueados a la espera de la cerradura y y usted no necesita a menudo para cambiar los datos.

Sin embargo, ReaderWriterLock puede bloquear un hilo que está esperando para escribir durante mucho tiempo.

Por tanto, sólo utilizar ReaderWriterLock después de que haya confirmó se obtiene alta contención para el bloqueo en “la vida real ” y han confirmado que no se puede rediseñar el diseño de bloqueo para reducir el tiempo que el bloqueo es celebrada por.

Considere también si no puede almacenar los datos compartidos en una base de datos y deje que se encargue de todo el bloqueo, ya que es mucho menos probable que esto le dificulte localizar errores, si es una base de datos lo suficientemente rápido para su aplicación.

En algunos casos también es posible que pueda utilizar la memoria caché Aps.net para manejar datos compartidos, y simplemente eliminar el elemento de la memoria caché cuando los datos cambian. La siguiente lectura puede poner una nueva copia en el caché.

Recuerde

"El mejor tipo de bloqueo es la de bloqueo que no es necesario (es decir, no hacer compartir datos entre hilos)."

Answer 3

monitor y el subyacente "syncblock" que puede estar asociada con cualquier objeto de referencia — el mecanismo subyacente bajo lock — apoyo ejecución exclusiva C# 's. Solo un hilo puede tener el candado. Esto es simple y eficiente.

ReaderWriterLock (o, en V3.5, mejor ReaderWriterLockSlim) proporcionan un modelo más complejo. Evitar a menos que sepa será más eficiente (es decir, tendrá mediciones de rendimiento para mantenerse).

El mejor tipo de bloqueo es el bloqueo que no necesita (es decir, no compartir datos entre hilos).

Answer 4

ReaderWriterLock le permite tener múltiples hilos para mantener el ReadLock al mismo tiempo ...para que sus datos compartidos puedan ser consumidos por muchos hilos a la vez. Tan pronto como se solicita un bloqueo de escritura, no se otorgan más bloqueos de lectura y el código en espera del bloqueo de escritura se bloquea hasta que todos los hilos con los bloqueos de lectura los hayan liberado.

El WriteLock tan sólo puede estar en poder de un hilo, permiten que aparezcan atómica desde el punto de vista de las partes consumidoras de su código de sus actualizaciones de datos ''.

la cerradura de la otra parte sólo permite un hilo para ingresar a la vez, sin margen para hilos que simplemente están tratando de consumir los datos compartidos.

ReaderWriterLockSlim es una nueva versión más eficaz de ReaderWriterLock con mejor soporte para la recursividad y la capacidad de tener un movimiento de hilo desde un bloqueo que es esencialmente un ReadLock a WriteLock sin problemas (UpgradeableReadLock).

Answer 5

Sugeriría que se vea aunque http://www.albahari.com/threading/ - la parte tres habla sobre ReaderWriterLockSlim (que desea utilizar en lugar de ReaderWriterLock).

Answer 6

ReaderWriterLock/Slim está diseñado específicamente para ayudar a bloquear de manera eficiente en un escenario de múltiples consumidor/productor individual. Hacerlo con la instrucción de bloqueo es posible, pero no eficiente. RWL/S obtiene la ventaja al ser capaz de realizar un spinlock agresivo para adquirir el bloqueo. Eso también te ayuda a evitar los convoyes de bloqueo, un problema con la sentencia de bloqueo en la que un hilo renuncia a su cantidad de subprocesos cuando no puede adquirir el bloqueo, lo que lo retrasa porque no se reprogramará durante un tiempo.

Answer 7

Es cierto que es más rápido que ReaderWriterLockSlim ReaderWriterLock. Pero el consumo de memoria de ReaderWriterLockSlim es francamente escandaloso. Intente conectar un perfilador de memoria y compruébelo usted mismo. Escogería ReaderWriterLock algún día sobre ReaderWriterLockSlim.