C# lock

Nas aulas de Task e Threads, você pôs o computador para fazer várias coisas ao mesmo tempo. Isso é ótimo enquanto cada tarefa mexe só nas suas coisas. O problema começa quando duas tarefas mexem na mesma variável no mesmo instante: o resultado sai errado, e cada vez errado de um jeito diferente. Nesta aula você vai ver esse erro acontecer de verdade e consertá-lo com a instrução lock ("trancar") e com o tipo Lock, novo no .NET 9.

Todas as saídas desta aula são reais: foram feitas com o .NET 10 (dotnet --version = 10.0.112) na máquina fictícia da Ana, um notebook com 8 núcleos, na pasta ~/cs/lock, com dotnet run arquivo.cs (veja Rodar com dotnet run).

A ideia: a chave do banheiro do posto

Num posto de estrada, o banheiro tem uma chave só, pendurada no balcão. Quem quer entrar pega a chave; quem chega depois espera no balcão até a chave voltar. Ninguém entra enquanto outra pessoa está lá dentro.

O lock é essa chave. Um pedaço do código vira o "banheiro": só uma thread por vez pode estar dentro dele. As outras ficam esperando, em fila, até a primeira sair. Esse pedaço protegido tem um nome técnico: seção crítica.

1. O problema: quatro tarefas, um contador

A Ana quer contar até 4 milhões, dividindo o trabalho entre 4 tarefas: cada uma soma 1 ao contador um milhão de vezes. A conta é fácil: 4 × 1.000.000 = 4.000.000.

int contador = 0;
var tarefas = new Task[4];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 1_000_000; j++)
        {
            contador++;
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Esperado: {4 * 1_000_000}");
Console.WriteLine($"Total:    {contador}");

int contador = 0;

A variável que as quatro tarefas vão dividir. Como a lambda () => { … } usa contador, todas as tarefas mexem na mesma variável, não numa cópia (veja Lambdas).

Task.Run(() => { … })

"Rode isto numa tarefa": o .NET pega uma thread livre e executa a lambda nela, ao mesmo tempo que as outras (veja Task).

contador++;

Soma 1. Parece uma coisa só, mas não é (veja logo abaixo).

await Task.WhenAll(tarefas);

Espera as quatro tarefas terminarem antes de mostrar o total.

A Ana rodou três vezes, sem mudar nada:

$ dotnet run contador.cs
Esperado: 4000000
Total:    2843643
$ dotnet run contador.cs
Esperado: 4000000
Total:    3213877
$ dotnet run contador.cs
Esperado: 4000000
Total:    2927090

O total está errado, e cada vez de um jeito. Sumiram mais de um milhão de somas. Não apareceu nenhum erro nem nenhum aviso: o compilador não tem como saber que quatro threads vão mexer na mesma variável. Esse tipo de erro se chama condição de corrida (em inglês, race condition): o resultado depende de quem "chega primeiro", e isso muda a cada execução.

Por que contador++ perde somas

Para o processador, contador++ são três passos: ler o valor da memória, somar 1, gravar o valor de volta. Veja o que acontece quando duas threads fazem isso no mesmo instante, com o contador valendo 10:

As duas somaram 1, mas o contador só andou 1: a soma da thread A foi apagada pela gravação da thread B. Com 8 núcleos trabalhando, isso acontece milhões de vezes.

2. A instrução lock

O conserto é deixar o contador++ dentro de um lock. Assim, só uma tarefa por vez faz os três passos:

int contador = 0;
object trava = new();
var tarefas = new Task[4];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 1_000_000; j++)
        {
            lock (trava)
            {
                contador++;
            }
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Esperado: {4 * 1_000_000}");
Console.WriteLine($"Total:    {contador}");

$ dotnet run contador2.cs
Esperado: 4000000
Total:    4000000
$ dotnet run contador2.cs
Esperado: 4000000
Total:    4000000

object trava = new();

A "chave do banheiro": um objeto qualquer, criado só para servir de trava. Ele não guarda nada; o que importa é que todas as tarefas usem o mesmo objeto. É a forma antiga, que funciona em qualquer versão do .NET (a forma nova está na seção 3).

lock (trava)

"Tranque com esta trava". Se a trava está livre, a thread a pega e entra no bloco. Se outra thread está com ela, esta espera ali, parada, até a trava ser devolvida.

{ contador++; }

A seção crítica: o que só uma thread por vez pode fazer. Ponha aqui tudo o que lê e muda os dados divididos, e nada além disso.

a chave do bloco }

Ao sair do bloco, a trava é devolvida e a próxima thread da fila entra. Isso acontece sempre: no fim normal, num return ou numa exceção.

A trava só funciona se for a mesma para todos. Se cada tarefa criasse a sua (lock (new object())), seria como um banheiro com uma chave para cada pessoa: todo mundo entra junto, e o total volta a sair errado.

O lock devolve a trava mesmo quando dá erro

Uma exceção lá dentro não deixa a trava presa. A propriedade IsHeldByCurrentThread ("está segura pela thread atual?") mostra isso:

Lock trava = new();

try
{
    lock (trava)
    {
        Console.WriteLine($"Dentro do lock: {trava.IsHeldByCurrentThread}");
        throw new InvalidOperationException("deu ruim");
    }
}
catch (InvalidOperationException e)
{
    Console.WriteLine($"Pegou: {e.Message}");
}

Console.WriteLine($"Depois do erro: {trava.IsHeldByCurrentThread}");

$ dotnet run excecao.cs
Dentro do lock: True
Pegou: deu ruim
Depois do erro: False

Por baixo, o compilador escreve o lock como um try/finally (veja finally): pega a trava, roda o bloco no try e devolve a trava no finally.

int contador = 0;
Lock trava = new();
var tarefas = new Task[4];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 100_000; j++)
        {
            contador++;
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Total: {contador}");

int contador = 0;
Lock trava = new();
var tarefas = new Task[4];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 100_000; j++)
        {
            lock (trava)
            {
                contador++;
            }
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Total: {contador}");

3. O tipo Lock C# 13

Até o .NET 8, a trava era sempre um object qualquer. O .NET 9 trouxe um tipo feito só para isso: System.Threading.Lock. Ele é mais rápido e deixa claro, só de ler, para que o campo serve. No .NET 10, é o jeito recomendado. Não precisa de using: o System.Threading já vem importado nos programas de console.

Basta trocar o tipo da trava; o lock continua igual:

int contador = 0;
Lock trava = new();
«… o resto, igual …»

$ dotnet run contador2.cs
Esperado: 4000000
Total:    4000000

O compilador do C# 13 em diante reconhece o tipo Lock no lock (…) e usa os métodos próprios dele. Com um object, ele usa o mecanismo antigo, o Monitor (veja a tabela "formas diferentes", abaixo).

Uma classe que se protege sozinha

Na vida real, a trava não fica solta no programa: ela fica dentro da classe que guarda os dados divididos, como um campo private readonly. Assim, quem usa a classe nem precisa saber que existe uma trava.

O caso: a conta conjunta da Ana e do Beto tem R$ 100,00. Os dois, cada um num caixa eletrônico, tentam sacar R$ 80,00 no mesmo instante. Primeiro, a versão sem trava (o Thread.Sleep(10) faz o caixa "pensar" 10 milissegundos entre conferir o saldo e descontar, como acontece num sistema de verdade, que consulta o banco de dados):

var conta = new Conta(100m);

var ana = new Thread(() => conta.Sacar(80m, "Ana"));
var beto = new Thread(() => conta.Sacar(80m, "Beto"));
ana.Start();
beto.Start();
ana.Join();
beto.Join();

Console.WriteLine($"Saldo final: {conta.Saldo:C}");

class Conta(decimal saldoInicial)
{
    public decimal Saldo { get; private set; } = saldoInicial;

    public void Sacar(decimal valor, string quem)
    {
        if (Saldo >= valor)
        {
            Thread.Sleep(10); // o caixa eletrônico "pensa" um pouco
            Saldo -= valor;
            Console.WriteLine($"{quem} sacou {valor:C}");
        }
        else
        {
            Console.WriteLine($"{quem}: saldo insuficiente");
        }
    }
}

$ dotnet run conta.cs
Beto sacou R$ 80,00
Ana sacou R$ 80,00
Saldo final: -R$ 60,00
$ dotnet run conta.cs
Ana sacou R$ 80,00
Beto sacou R$ 80,00
Saldo final: -R$ 60,00

Os dois conferiram o saldo (R$ 100,00, dá para sacar), os dois sacaram, e a conta ficou negativa. É o padrão "confere e depois faz" (em inglês, check-then-act): entre a conferência e a ação, outra thread mudou o mundo. Na primeira tentativa da Ana, o saldo final saiu até R$ 20,00, porque as duas threads leram R$ 100,00 e gravaram R$ 20,00 por cima uma da outra, o mesmo problema do contador. Cada execução pode errar de um jeito.

Agora com a trava. A conferência e o desconto ficam no mesmo lock:

class Conta(decimal saldoInicial)
{
    private readonly Lock _trava = new();
    public decimal Saldo { get; private set; } = saldoInicial;

    public void Sacar(decimal valor, string quem)
    {
        lock (_trava)
        {
            if (Saldo >= valor)
            {
                Thread.Sleep(10); // o caixa eletrônico "pensa" um pouco
                Saldo -= valor;
                Console.WriteLine($"{quem} sacou {valor:C}");
            }
            else
            {
                Console.WriteLine($"{quem}: saldo insuficiente");
            }
        }
    }
}

$ dotnet run conta2.cs
Ana sacou R$ 80,00
Beto: saldo insuficiente
Saldo final: R$ 20,00

private

Só a própria classe enxerga a trava. Ninguém de fora consegue trancá-la por engano (nem esquecer de trancar).

readonly

"Só leitura": a trava nunca é trocada por outra. Se alguém fizesse _trava = new(); no meio do programa, threads diferentes passariam a usar chaves diferentes.

Lock _trava = new();

Uma trava para cada conta. Contas diferentes não esperam umas pelas outras: o Beto sacando da conta dele não atrapalha a Ana sacando da dela.

lock (_trava) { if … Saldo -= valor; }

A conferência e o desconto viraram uma coisa só, que ninguém interrompe. Quem chega depois espera e encontra o saldo já atualizado.

Quem sacou primeiro (Ana ou Beto) pode mudar de uma execução para outra: isso é normal com threads. O que o lock garante é que só um dos dois consegue, e que o saldo final é sempre R$ 20,00.

4. EnterScope e TryEnter

O lock (…) resolve quase tudo. Para os casos especiais, o tipo Lock tem métodos próprios:

Lock trava = new();

using (trava.EnterScope())
{
    Console.WriteLine($"Dentro: {trava.IsHeldByCurrentThread}");
}
Console.WriteLine($"Fora: {trava.IsHeldByCurrentThread}");

if (trava.TryEnter())
{
    try
    {
        Console.WriteLine("Consegui a trava com TryEnter");
    }
    finally
    {
        trava.Exit();
    }
}

$ dotnet run escopo.cs
Dentro: True
Fora: False
Consegui a trava com TryEnter

trava.EnterScope()

"Entre num escopo": pega a trava e devolve um objeto que, no fim do using, a solta (veja using). É exatamente o que o lock (trava) faz por baixo quando a trava é um Lock.

trava.TryEnter()

"Tente entrar": se a trava está livre, pega e devolve true; se está ocupada, devolve false na hora, sem esperar. Serve para "se o banheiro estiver ocupado, vou fazer outra coisa". Existe também TryEnter(TimeSpan.FromSeconds(1)), que espera no máximo esse tempo.

try { … } finally { trava.Exit(); }

Com TryEnter, devolver a trava é com você: Exit() ("sair") no finally, para devolver mesmo se der erro.

5. Para uma soma só: Interlocked

Quando o que você precisa proteger é uma única operação num número (somar 1, subtrair, trocar o valor), existe um atalho mais leve que o lock: a classe Interlocked ("travado entre si"). Ela pede ao processador que faça os três passos (ler, somar, gravar) como um só, que ninguém interrompe. Uma operação assim se chama atômica (do grego átomo, "que não se divide").

int contador = 0;
var tarefas = new Task[4];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 1_000_000; j++)
        {
            Interlocked.Increment(ref contador);
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Total: {contador}");

$ dotnet run inter.cs
Total: 4000000

Interlocked.Increment(ref contador)

Soma 1 de forma atômica. O ref entrega a própria variável, não uma cópia do valor (veja ref, out e in).

Outros métodos

Interlocked.Decrement(ref x) (subtrai 1), Interlocked.Add(ref x, 5) (soma 5), Interlocked.Exchange(ref x, 0) (troca o valor e devolve o antigo).

O Interlocked só serve para uma variável e uma operação. O saque da conta (conferir o saldo e descontar) são duas coisas que precisam acontecer juntas: aí, só o lock resolve.

int visitas = 0;
var tarefas = new Task[3];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 100; j++)
        {
            visitas++;
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Visitas: {visitas}");

int visitas = 0;
var tarefas = new Task[3];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() =>
    {
        for (int j = 0; j < 100; j++)
        {
            Interlocked.Increment(ref visitas);
        }
    });
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Visitas: {visitas}");

Formas diferentes: qual usar

Quando dá errado

Lock caneta = new();
Lock caderno = new();

var ana = new Thread(() =>
{
    lock (caneta)
    {
        Console.WriteLine("Ana pegou a caneta");
        Thread.Sleep(100);
        Console.WriteLine("Ana espera o caderno...");
        lock (caderno)
        {
            Console.WriteLine("Ana escreveu");
        }
    }
});
var beto = new Thread(() =>
{
    lock (caderno)
    {
        Console.WriteLine("Beto pegou o caderno");
        Thread.Sleep(100);
        Console.WriteLine("Beto espera a caneta...");
        lock (caneta)
        {
            Console.WriteLine("Beto escreveu");
        }
    }
});
ana.Start();
beto.Start();
ana.Join();
beto.Join();
Console.WriteLine("Fim");

$ timeout 10 dotnet run impasse.cs; echo "código de saída: $?"
Ana pegou a caneta
Beto pegou o caderno
Ana espera o caderno...
Beto espera a caneta...
código de saída: 124

int trava = 0;
lock (trava)
{
    Console.WriteLine("dentro");
}

$ dotnet run erro1.cs
/home/ana/cs/lock/erro1.cs(2,7): error CS0185: "int" não é um tipo de referência como necessário pela instrução lock

Ocorreu uma falha no build. Corrija os erros de build e execute novamente.

object trava = new();
lock (trava)
{
    await Task.Delay(100);
}

$ dotnet run erro2.cs
/home/ana/cs/lock/erro2.cs(4,5): error CS1996: Não é possível aguardar no corpo de uma instrução lock

Ocorreu uma falha no build. Corrija os erros de build e execute novamente.

$ dotnet run escopo2.cs
/home/ana/cs/lock/escopo2.cs(2,8): error CS4007: A instância do tipo "System.Threading.Lock.Scope" não pode ser preservada entre o limite "await" ou "yield".

Ocorreu uma falha no build. Corrija os erros de build e execute novamente.

object trava = new Lock();
lock (trava)
{
    Console.WriteLine("dentro");
}

$ dotnet run aviso.cs
/home/ana/cs/lock/aviso.cs(1,16): warning CS9216: Um valor do tipo "System.Threading.Lock" convertido em um tipo diferente usará o bloqueio baseado em monitor provavelmente não intencional na instrução "lock".
dentro

Lock trava = new();
trava.Exit();

$ dotnet run sair.cs; echo "código de saída: $?"
Unhandled exception. System.Threading.SynchronizationLockException: The calling thread does not hold the lock.
   at System.Threading.Lock.Exit()
   at Program.<Main>$(String[] args) in /home/ana/cs/lock/sair.cs:line 2
código de saída: 134

Referência rápida

Exercícios

Missão final: o estoque da lojinha

var estoque = new Estoque(10);
var tarefas = new Task[20];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() => estoque.Vender());
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Vendidos: {estoque.Vendidos}");
Console.WriteLine($"Sobrou: {estoque.Quantidade}");

class Estoque(int quantidade)
{
    public int Quantidade { get; private set; } = quantidade;
    public int Vendidos { get; private set; }

    public void Vender()
    {
        if (Quantidade > 0)
        {
            Quantidade--;
            Vendidos++;
        }
    }
}

var estoque = new Estoque(10);
var tarefas = new Task[20];

for (int i = 0; i < tarefas.Length; i++)
{
    tarefas[i] = Task.Run(() => estoque.Vender());
}

await Task.WhenAll(tarefas);
Console.WriteLine($"Vendidos: {estoque.Vendidos}");
Console.WriteLine($"Sobrou: {estoque.Quantidade}");

class Estoque(int quantidade)
{
    private readonly Lock _trava = new();
    public int Quantidade { get; private set; } = quantidade;
    public int Vendidos { get; private set; }

    public void Vender()
    {
        lock (_trava)
        {
            if (Quantidade > 0)
            {
                Quantidade--;
                Vendidos++;
            }
        }
    }
}

Resumo

• Quando várias threads mexem na mesma variável, o resultado pode sair errado e diferente a cada execução: é a condição de corrida. Nem o compilador nem o programa avisam.
• contador++ são três passos (ler, somar, gravar); duas threads no meio deles perdem somas.
• lock (trava) { … } deixa só uma thread por vez dentro do bloco e devolve a trava sempre, mesmo com exceção.
• No .NET 9 e no .NET 10, a trava recomendada é private readonly Lock _trava = new(); C# 13. A forma antiga usa object.
• "Confere e depois faz" (o saque, a venda) vai inteiro dentro do mesmo lock.
• Para uma operação só num número, Interlocked.Increment(ref x) é mais leve.
• Sem await dentro do lock (CS1996); duas travas, sempre na mesma ordem, para evitar o impasse.