05. Condições de corrida e seções críticas

Este capítulo nasce das 30 questões publicadas sobre Condições de corrida e seções críticas. A leitura do acervo revelou 30 núcleos de conhecimento, aqui reorganizados como uma explicação progressiva: primeiro o vocabulário e o modelo mental, depois os mecanismos, as decisões de implementação, os limites e a forma de verificar o comportamento do sistema.

Com modelos e componentes definidos, estudamos tarefas que avançam no tempo e disputam recursos. Ordem, estado compartilhado, sincronização, cancelamento e falhas precisam ser analisados em conjunto. Este é o capítulo 5 de 20 da disciplina Programação Assíncrona e Concorrência. Ele retoma Escalonamento e troca de contexto e utiliza essa base para avançar. Na sequência, estudaremos Mutex, semáforos e monitores.

O fio condutor

O desenvolvimento de software começa com um problema e avança por decisões que precisam permanecer compreensíveis e verificáveis. Requisitos orientam modelos; modelos orientam código e arquitetura; testes verificam comportamento; e a operação devolve informações para o próximo ciclo. Uma falha importante no início tende a se espalhar pelas etapas seguintes.

Neste capítulo, use Condições de corrida e seções críticas para acompanhar quatro perguntas: qual problema precisa ser resolvido, como o mecanismo funciona, que consequências a escolha produz e como o resultado será verificado. Essa sequência transforma termos técnicos em decisões que podem ser explicadas e testadas.

Parte 1 — Fundamentos e vocabulário

Começamos por Parte 1 — Fundamentos e vocabulário, pois essa base organiza os conceitos e exemplos que aparecerão no restante do capítulo.

Data race

O ponto de partida é estabelecer o significado do conceito e o problema que ele procura organizar. Data race descreve um conflito de acessos à memória: duas execuções acessam a mesma posição concorrentemente, ao menos uma escreve e não há ordenação de sincronização suficiente. Race condition é a categoria semântica mais ampla em que o resultado correto depende da ordem ou do instante dos eventos. Um fluxo check-then-act envolvendo banco de dados pode, por exemplo, sofrer race condition mesmo sem configurar data race na memória do processo. Distinguir os termos evita concluir que uma ferramenta de detecção de acessos à memória encontra toda falha de concorrência. A regra ganha sentido quando suas consequências orientam a implementação.

Para aplicar Data race, acompanhe a execução desde a entrada até a saída e anote pré-condições, mudança de estado, custo e falhas possíveis. Assim o conceito deixa de ser um rótulo e passa a orientar decisões.

Use como teste da compreensão: Uma data race exige acessos concorrentes ao mesmo local de memória, sem sincronização adequada, com pelo menos um acesso de escrita; já uma race condition é um conceito mais amplo, pois pode existir sempre que a correção depender de uma intercalação temporal desfavorável. Depois verifique a afirmação com execução controlada, teste automatizado, análise do contrato, medição ou documentação da versão correspondente. A evidência deve reproduzir a propriedade afirmada, inclusive nos casos de erro e de fronteira.

Incremento normalmente

A partir dessa distinção, o próximo elemento completa o fluxo. O incremento normalmente representa uma sequência read-modify-write: ler o valor, calcular o sucessor e gravá-lo. Mesmo que cada leitura e cada escrita isoladas sejam atômicas, duas threads podem ler o mesmo valor antigo e uma atualização se perder. Alinhamento pode ser relevante para a atomicidade de acessos simples em certas arquiteturas, mas não transforma automaticamente uma operação composta da linguagem em incremento atômico. A correção requer uma primitiva como fetch-and-add, uma classe atômica ou exclusão mútua. A confusão frequente consiste em confundir atomicidade da palavra de memória com atomicidade da expressão inteira. Observe como definição, mecanismo e efeito permanecem ligados.