APRENDER. PRATICAR. EVOLUIR.O que foi realmente executado
O laboratório inicia workers Python separados e cria um ficheiro de estado inventado e um ficheiro de lock numa diretoria temporária privada. O primeiro worker obtém LOCK_EX com LOCK_NB. Um segundo tenta o mesmo objeto e termina com código 75 quando encontra contenção. Este código é uma escolha da aplicação; não corresponde a uma prioridade operacional nem prova que exista uma fila. O primeiro titular continua vivo e consegue escrever. Os grupos passaram duas vezes em CPython 3.13.1, Darwin arm64. A documentação Python descreve a interface Unix; os manuais Apple consultados estão arquivados. Por isso, separa a referência histórica do resultado observado neste sistema, sem generalizar para um cluster ou filesystem remoto.
Acesso exclusivo não renova o plano
O estado começa na revisão 7. A confirma essa revisão e escreve change-a na revisão 8. Depois de A sair, B obtém o lock, mas o seu pedido ainda espera 7: o worker devolve stale e mantém o valor existente. O guião reapresenta uma decisão explicitamente reavaliada para 8 e escreve change-b na revisão 9. Repetir o pedido baseado em 8 é novamente rejeitado. Numa mudança fictícia de middleware, uma intervenção ocorrida durante a espera pode alterar dependências ou configuração. Não basta mudar o número esperado. Inspeciona a diferença, confirma o efeito pretendido e obtém a decisão exigida pelo processo aplicável. O laboratório modela uma revisão simples, não autentica aprovadores nem implementa um workflow de autorização.
O perímetro de cooperação
Com B ainda ativo e titular do lock, o guião inicia outro processo que escreve diretamente revisão 10 com outside-protocol. Esse processo não pede o lock. A leitura seguinte de B encontra 10 e rejeita uma operação baseada em 9. O ensaio mostra deteção da alteração que foi deliberadamente concluída antes da leitura, mas também mostra que o lock consultivo não impediu o escritor externo. Numa ferramenta APS, inventaria automação, consolas administrativas, scripts antigos e caminhos de emergência. Todos os escritores relevantes precisam de um controlo coerente ou de outra proteção adequada. Escolher um ficheiro de lock por projeto também pode deixar dois projetos sem coordenação quando alteram o mesmo recurso; o âmbito deve corresponder ao estado efetivamente partilhado.
A janela continua a contar durante a espera
Obter um recurso resolve apenas uma condição de execução. Se restam oito minutos e o plano exige dez de aplicação, seis de validação e oito de recuperação, a sequência já não cabe na janela. Não uses o sucesso de aquisição para justificar início automático, nem consumes a reserva de recuperação sem uma decisão válida. Revê dependências, pessoas disponíveis, estado atual e autorização para o período de impacto. Num comité fictício, comunica a causa da espera, o tempo útil e as opções de reagendamento ou extensão. O valor do lock é técnico e limitado; não substitui a coordenação com o responsável pelo serviço. Os tempos deste exemplo são inventados para praticar a decisão, não um SLA ou norma de um banco.
python3 content/labs/change-coordination/run.py --output /tmp/dr-change-coordination.json
# Observe secondOwnerRejected and acquisitionDoesNotRefreshPlan.
# Use only the private disposable resources created by the lab.A escreve revisão 8; B obtém o lock depois, mas o pedido preparado para revisão 7 é rejeitado sem escrever.
Armadilhas comuns
Tratar aquisição como autorização, alterar expectedRevision só para passar ou presumir que um lock impede todos os escritores.
Tópicos relacionados: Janelas e dependências · Identidade dos recursos e recuperação
O controlo só cobre participantes que partilham o mesmo objeto; obter acesso não renova automaticamente os pressupostos do plano.
Referência: Archived Mac OS X manual: flock(2) · DR Change Management 2026.1; independent technical curriculum