ReaderWriterLock vs bloqueio {}

Por favor, explique quais são as principais diferenças e quando devo usar o quê.
O foco em aplicativos multi-threaded da web.

O bloqueio permite que apenas um thread execute o código ao mesmo tempo. O ReaderWriterLock pode permitir que vários segmentos sejam lidos ao mesmo tempo ou tenham access exclusivo para gravação, portanto, pode ser mais eficiente. Se você estiver usando o .NET 3.5 ReaderWriterLockSlim é ainda mais rápido. Portanto, se o seu recurso compartilhado estiver sendo lido com mais frequência do que escrito, use o ReaderWriterLockSlim . Um bom exemplo para usá-lo é um arquivo que você lê com muita frequência (em cada solicitação) e atualiza o conteúdo do arquivo raramente. Assim, quando você lê o arquivo, você insere um bloqueio de leitura para que muitas solicitações possam ser abertas para leitura e, quando você decide escrever, você insira um bloqueio de gravação. Usar um lock no arquivo significa basicamente que você pode atender a um pedido de cada vez.

Considere o uso do ReaderWriterLock se você tiver muitos encadeamentos que precisem apenas ler os dados, e esses encadeamentos estejam bloqueados aguardando o bloqueio e não seja necessário alterar os dados com freqüência.

No entanto ReaderWriterLock pode bloquear um thread que está aguardando para gravar por um longo tempo.

Portanto, use somente o ReaderWriterLock após confirmar que você obtém alta contenção pelo bloqueio na ” vida real ” e confirmou que não é possível reprojetar seu design de bloqueio para reduzir por quanto tempo o bloqueio é mantido .

Considere também se você não pode armazenar os dados compartilhados em um database e deixá-los cuidar de todos os bloqueios, já que é muito menos provável que você tenha dificuldade em rastrear bugs, se um database for rápido o suficiente para o seu database. aplicação.

Em alguns casos, você também poderá usar o cache do Aps.net para manipular dados compartilhados e apenas remover o item do cache quando os dados forem alterados. A próxima leitura pode colocar uma nova cópia no cache.

Lembrar

“O melhor tipo de bloqueio é o bloqueio que você não precisa (ou seja, não compartilhe dados entre threads).”

Monitor e o “syncblock” subjacente que pode ser associado a qualquer object de referência – o mecanismo subjacente sob o lock C # – suporta a execução exclusiva. Apenas um thread pode ter o bloqueio. Isso é simples e eficiente.

ReaderWriterLock (ou, na V3.5, o melhor ReaderWriterLockSlim ) fornece um modelo mais complexo. Evite a menos que você saiba que será mais eficiente (ou seja, ter medidas de desempenho para se sustentar).

O melhor tipo de bloqueio é o bloqueio que você não precisa (ou seja, não compartilhe dados entre threads).

O ReaderWriterLock / Slim foi projetado especificamente para ajudá-lo a bloquear com eficiência um cenário de vários consumidores / produtores individuais. Fazer isso com a instrução de bloqueio é possível, mas não é eficiente. O RWL / S ganha vantagem ao ser capaz de girar de forma agressiva para obter o bloqueio. Isso também ajuda a evitar os comboios de bloqueio, um problema com a instrução de bloqueio em que um thread libera o quantum de thread quando não consegue adquirir o bloqueio, fazendo com que ele fique para trás porque não será remarcado por um tempo.

O ReaderWriterLock permite que vários threads mantenham o ReadLock ao mesmo tempo … para que seus dados compartilhados possam ser consumidos por vários threads de uma só vez. Assim que um WriteLock é solicitado, não são concedidos mais ReadLocks e o código aguardando o WriteLock é bloqueado até que todos os threads com ReadLocks os tenham liberado.

O WriteLock só pode ser mantido por um thread, permitir que suas ‘atualizações de dados’ apareçam atômicas do ponto de vista das partes consumidoras do seu código.

O bloqueio, por outro lado, permite que apenas um segmento seja inserido por vez, sem permissão para encadeamentos que estão simplesmente tentando consumir os dados compartilhados.

O ReaderWriterLockSlim é uma nova versão de desempenho do ReaderWriterLock com melhor suporte para recursion e a capacidade de mover um thread de um Lock que é essencialmente um ReadLock para o WriteLock suavemente (UpgradeableReadLock).

É verdade que ReaderWriterLockSlim é mais rápido que ReaderWriterLock. Mas o consumo de memory do ReaderWriterLockSlim é completamente escandaloso. Tente append um perfilador de memory e veja por si mesmo. Eu escolheria ReaderWriterLock a qualquer dia sobre ReaderWriterLockSlim.

Eu sugeriria olhar embora http://www.albahari.com/threading/ – parte três fala sobre ReaderWriterLockSlim (que você quer usar em vez de ReaderWriterLock).