Pergunta

Em .net4, Monitor.enter (objeto) é marcado como obsoleto:

[ObsoleteAttribute("This method does not allow its caller to reliably release the lock.  Please use an overload with a lockTaken argument instead.")]
public static void Enter(
    Object obj
)

E há um novo método Monitor.Enter (LockObject, adquirtedlock) Com este uso:

bool acquiredLock = false;

try
{
    Monitor.Enter(lockObject, ref acquiredLock);

    // Code that accesses resources that are protected by the lock.

}
finally
{
    if (acquiredLock)
    {
        Monitor.Exit(lockObject);
    }
}

Eu costumava fazer desta maneira:

Monitor.Enter(lockObject);
try
{

    // Code that accesses resources that are protected by the lock.
}
finally
{
    Monitor.Exit(lockObject);
}

Está errado? Por quê ? Talvez com um interrupto após o Enter, mas antes da tentativa?
Como Eamon Nerbonne perguntou: O que acontece se houver uma exceção assíncrona no Finalmente Antes do Monitor.Exit?

Responda : ThreadAborTexception

Quando essa exceção é aumentada, o tempo de execução executa todos os blocos finalmente antes de terminar o thread.

Foi útil?

Solução

Como você sugere logo no final da questão, o problema é que um exceção assíncrona poderia ser jogado após a chamada para Monitor.Enter Mas antes de entrar no try quadra.

A nova maneira de fazer as coisas garante que, aconteça o que acontecer, você atingirá o bloco finalmente e poderá liberar o bloqueio E se você adquiriu. (Você não pode adquiri -lo se Monitor.Enter joga uma exceção, por exemplo.)

Iirc, este é o novo comportamento do lock palavra -chave ao segmentar .NET 4.0.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top