O lock e o nome dele

Dois engenheiros olham o mesmo gráfico. O Puma roda dezesseis threads, a máquina tem oito núcleos, e a CPU fica em 12% enquanto a latência p95 sobe. Um diz "o problema é o GIL". O outro diz "nem estamos presos em CPU, põe mais threads". Os dois discutem sobre uma trava que nenhum deles jamais mediu.

Essa trava tem nome, e a primeira coisa a acertar é qual. No CRuby o mecanismo se chama Global VM Lock, ou GVL. Você também vai ouvir GIL, de Global Interpreter Lock. É o termo do Python, e foi o nome antigo que o próprio Ruby usava para a mesma coisa. Os dois se referem à mesma trava. GVL é o que a API C do MRI usa, em nomes de função como rb_thread_call_without_gvl, e é o nome que este curso usa daqui em diante.

O nome importa um pouco mais do que preciosismo, porque "trava da VM" diz a coisa útil e "trava do interpretador" não. A trava protege o estado da própria máquina virtual. Ela não protege o seu.

O que você já acredita, e por que não basta

O curso de nível Sênior "Ruby: concorrência" começou com uma medição: threads somando quadrados levaram o mesmo tempo que fazer o trabalho uma parte depois da outra. Ele nomeou a causa, uma trava global, e parou ali de propósito, porque a consequência era tudo de que você precisava para escolher um modelo.

Agora você já passou da escolha. A consequência sozinha não responde às perguntas que surgem num incidente de produção:

• Por que threads ajudam um endpoint pesado em banco, mas não um pesado em template?
• Se só uma thread roda por vez, por que o meu contador ainda erra?
• Quantas threads do Puma são certas para esta aplicação especificamente, e não em geral?
• Estou mesmo preso no GVL agora, ou estou chutando?

Cada uma tem resposta real. Nenhuma se alcança a partir de "só uma thread roda Ruby por vez".

O formato do mecanismo

Imagine o interpretador como uma sala com uma única chave. Uma thread não executa bytecode Ruby sem segurar a chave. Ela solta a chave em duas situações: quando vai esperar por algo fora do Ruby, e quando o timer da VM a cutuca porque ela já segurou a chave tempo demais.

thread A  [--ruby--]        [--ruby--]
thread B            [--ruby--]        [--ruby--]
                    ^                 ^
                    |                 |
              A bloqueou em I/O  timer preemptou A

Dois pontos de liberação têm consequências completamente diferentes. A liberação no I/O é o motivo de servidores web com threads funcionarem. A liberação pelo timer é o motivo de o seu contador sem sincronização poder errar.

O que este curso cobre

A lição 2 abre a sala. Ela cobre quais partes do estado do interpretador a trava protege, por que o caminho de alocação de objetos e o coletor de lixo estão nessa lista, e por que o seu @balance não está.

A lição 3 é a consequência que os engenheiros mais erram. O GVL não deixa o seu código thread-safe, e você vai ver um contador perder a maior parte dos incrementos para provar isso. Essa lição traz o desafio de código.

A lição 4 é a liberação em volta de trabalho bloqueante: dormir, ler um socket e extensões C que devolvem a chave de propósito com rb_thread_call_without_gvl. Esse mecanismo está por trás da afirmação de que threads ajudam no I/O.

A lição 5 é o modelo de troca: preempção por timer, medida aqui em cerca de 100 ms, Thread.pass e o que o escalonador M:N introduzido no Ruby 3.3 muda e não muda.

A lição 6 é a habilidade que todo o resto existe para sustentar: medir. Ela compara tempo de relógio com tempo de CPU e execuções sequenciais com execuções em threads, e mostra como ler os dois números juntos.

A lição 7 entra num processo Rails, confronta o número de threads do Puma com o GVL e pergunta onde os Ractors deixam tudo isso.

Comece pela sala e pela chave. Quase toda crença errada sobre o GVL vem de supor que ele protege algo em que nunca tocou.