Concorrência e Paralelismo em Ruby
Software concorrente, paralelismo, múltiplas threads, esses assuntos sempre acabam surgindo, independentemente do seu nível de senioridade. Por muito tempo, esses temas foram verdadeiros pesadelos para mim. Eu me lembro de estudar concorrência usando C na faculdade. Eu fazia os exercícios, e eles funcionavam, mas, por muito tempo, parecia que eu não entendia muito bem como o computador conseguia fazer a "mágica" de executar meus programas de forma mais "rápida".
Este guia foi feito para abordar os conceitos de processos, clone de processos e threads, usando Ruby como linguagem base.
Ruby: Uma Linguagem Amigável e Elegante
Ruby é uma linguagem de programação interpretada e multi paradigma, com tipagem dinâmica e gerenciamento automático de memória. O interpretador mais comum é o MRI, sigla para Matz's Ruby Interpreter, também conhecido como CRuby por ser implementado em C. Ele é considerado o interpretador padrão da linguagem e o mais amplamente utilizado pela comunidade.
MRI por padrão oferece suporte a tão falada concorrência.
| Recurso | Suporte? |
|---|---|
| Threads | ✅ Sim |
| Fork | ✅ Sim |
| Processos | ✅ Sim |
Vamos utilizar duas versões diferentes de interpretadores Ruby para os testes. Para alternar entre eles de forma fácil e rápida, usaremos o gerenciador de versões rbenv.
Comandos para instalar as versões usadas aqui:
rbenv install 3.3.5
rbenv install jruby-9.4.8.0
Comando para usar uma versão especifica de forma global:
rbenv global 3.3.5
Comando para listar as versões instaladas:
rbenv versions
Saída
system
* 3.3.5 (set by /home/michael/.rbenv/version)
jruby-9.4.8.0
Processos
Usaremos o Ubuntu como sistema operacional, ou seja, os conceitos abordados aqui se aplicam a sistemas do tipo UNIX-like.
Os programas que rodam no seu Sistema operacional estão dentro de uma estrutura chamada processos. Os processos são independentes entre si e tem seus próprios recursos, como espaço em memória. O sistema operacional é inteligente o suficiente para gerenciar esses processos de forma simultânea usando um escalonador preemptivo. O fato de cada processo ter seu próprio espaço na memória permite que o sistema operacional lide com eles de forma concorrente. Ele consegue fazer trocas de contexto (context switch), aumentando a eficiência no uso da CPU.
Exemplo: você está assistindo a um vídeo no YouTube, editando um texto no LibreOffice e recebendo mensagens no seu Telegram, cada tarefa dessa é um processo.
Sua CPU tem múltiplos núcleos, mas você provavelmente tem dezenas de processos ativos. O sistema operacional faz a troca de contexto entre esses processos em questão de milissegundos, salvando o estado do processo atual e carregando o de outro.
É possivel listar os processos ativos do seu sistema com o comando top.
Segundo o manual (man top): The top program provides a dynamic real-time view of a running system.
Cada processo possui um estado próprio e é identificado por um PID (Process ID). O sistema operacional reconhece os processos como uma unidade de concorrência. Os processos também podem se comunicar entre si por meio de IPC (Inter-Process Communication), um conjunto de mecanismos que permite essa troca de informações.
É possível criar um processo filho por meio da syscall clone do sistema operacional.
O que é uma syscall? é um mecanismo pelo qual um programa de computador solicita serviços ao kernel do sistema operacional no qual ele está sendo executado
Quando essa chamada é executada, o processo pai é clonado, e um novo processo filho é criado com uma cópia do seu espaço de memória, fila de execução e descritores de arquivos, tudo isso dependendo dos parâmetros passados à syscall.
Segue a documentação da syscall clone diretamente do manual Linux https://man7.org/linux/man-pages/man2/clone3.2.html
Vamos criar um processo filho a partir de um processo pai utilizando fork em Ruby.
puts "Processo pai: PID = #{Process.pid}"
pid = fork do
puts "Processo filho: PID = #{Process.pid}, PPID = #{Process.ppid}"
sleep 2
puts "Processo filho terminou."
end
puts "Processo pai continua executando..."
Process.wait(pid)
puts "Processo pai terminou após o filho."
Saida
Processo pai: PID = 2864854
Processo pai continua executando...
Processo filho: PID = 2864890, PPID = 2864854
Processo filho terminou.
Processo pai terminou após o filho.
=> nil
O processo pai imprime seu próprio PID e, em seguida, cria um processo filho usando fork. O filho imprime seu PID e o do pai (PPID), simulando uma tarefa demorada com sleep. Enquanto isso, o pai continua executando, aguarda a finalização do filho com Process.wait, e só então encerra sua execução.
É possivel que um processo filho se comunique com o processo principal através de mensagens (pipe), no ruby conseguimos fazer essa comunicação usando IO.pipe
reader, writer = IO.pipe
pid = fork do
reader.close
writer.puts "Olá do processo filho!"
writer.close
end
writer.close
mensagem = reader.gets
puts "Pai recebeu: #{mensagem}"
reader.close
Process.wait(pid)
Saída
Pai recebeu: Olá do processo filho!
=> 2866592
Threads
Agora que falamos um pouco sobre processos, vamos falar das threads. Threads são como "partes" de um processo, elas compartilham os mesmos recursos como a memória com o processo principal e com outras threads do mesmo processo. Enquanto um processo é um contêiner que possui memória, recursos e ao menos uma thread, as threads são unidades de execução dentro desse contêiner, trabalhando de forma colaborativa no mesmo espaço de memória.
As threads são úteis quando queremos executar múltiplas tarefas simultaneamente dentro de um único processo, oferecendo uma forma leve e eficiente de alcançar a tão desejada concorrência.
Vamos escrever um programa que cria 4 threads que executam um cálculo de raiz quadrada.
Cada thread calcula a soma das raízes quadradas dos números de 0 até 99.999.999, totalizando 400 milhões de operações (Sim é bastante coisa). O programa utiliza a biblioteca Benchmark para medir e exibir o tempo total gasto para que todas as threads concluam o processamento.
require 'benchmark'
require 'date'
NUM_THREADS = 4
WORK_PER_THREAD = 100_000_000
def trabalho_pesado(pid)
total = 0
WORK_PER_THREAD.times do |i|
total += Math.sqrt(i)
end
puts "Thread #{pid} terminou! #{DateTime.now}"
total
end
puts "Iniciando benchmark com #{NUM_THREADS} threads... em #{DateTime.now}"
tempo = Benchmark.realtime do
threads = NUM_THREADS.times.map do
Thread.new do
pid = Thread.current.object_id
puts "Thread trabalhando: #{pid}"
trabalho_pesado(pid)
end
end
threads.each(&:join)
end
puts "Tempo total: #{tempo.round(2)} segundos"
Saída
Iniciando benchmark com 4 threads... em 2025-05-18T12:15:31-03:00
Thread trabalhando: 31440
Thread trabalhando: 31460
Thread trabalhando: 31480
Thread trabalhando: 31500
Thread 31500 terminou! 2025-05-18T12:16:04-03:00
Thread 31500 terminou! 2025-05-18T12:16:05-03:00
Thread 31500 terminou! 2025-05-18T12:16:05-03:00
Thread 31500 terminou! 2025-05-18T12:16:05-03:00
Tempo total: 34.12 segundos
=> nil
Nosso programa levou 34,12 segundos para executar todas essas operações. Pode parecer rápido, mas ainda podemos melhorar. Nesse caso, usamos concorrência para dividir a carga em 4 threads, que trabalham de forma concorrente, mas não em paralelo. Por que não em paralelo? Será que Ruby não escala?
O MRI utiliza um mecanismo chamado GIL (Global Interpreter Lock), que garante que apenas uma thread Ruby execute código Ruby por vez, mesmo em máquinas com múltiplos núcleos. Ou seja, o MRI não é thread safe em nível interno para algumas operações. O GIL impede que múltiplas threads executem código Ruby simultaneamente, evitando problemas de concorrência no gerenciamento de memória e objetos.
Agora, o que faremos é mudar o interpretador. Até aqui usamos o padrão MRI para os testes, mas vamos migrar para uma implementação que roda sobre a máquina virtual Java, o JRuby. Esse interpretador permite o paralelismo real entre threads, o que pode melhorar o desempenho nesse caso.
Vamos mudar a versão do Ruby usando o gerenciador rbenv.
rbenv global jruby-9.4.8.0
ruby --version
Saída
jruby 9.4.8.0 (3.1.4) 2024-07-02 4d41e55a67 OpenJDK 64-Bit Server VM 11.0.26+4-post-Ubuntu-1ubuntu122.04 on 11.0.26+4-post-Ubuntu-1ubuntu122.04 +jit [x86_64-linux
Agora que mudamos o interpretador para JRuby, vamos executar o mesmo código novamente. E o resultado é bem diferente...
Iniciando benchmark com 4 threads... em 2025-05-18T12:24:29-03:00
Thread trabalhando: 4004
Thread trabalhando: 4000
Thread trabalhando: 4008
Thread trabalhando: 4012
Thread 4012 terminou! 2025-05-18T12:24:43-03:00
Thread 4000 terminou! 2025-05-18T12:24:43-03:00
Thread 4008 terminou! 2025-05-18T12:24:43-03:00
Thread 4004 terminou! 2025-05-18T12:24:43-03:00
Tempo total: 13.48 segundos
Nosso programa, interpretado pelo JRuby, levou apenas 13,48 segundos para realizar os 400 milhões de cálculos. Isso representa uma execução aproximadamente 2,5 vezes mais rápida, ou cerca de 60,5% de ganho em desempenho em comparação com o MRI. Essa diferença acontece porque o JRuby consegue aproveitar os múltiplos núcleos do processador (A Java Virtual Machine é thread safe), aplicando paralelismo real entre as threads do programa.
Isso quer dizer que, para esse programa, precisamos mudar de interpretador para usar paralelismo? Não necessariamente. Podemos continuar usando o MRI e ainda assim aproveitar múltiplos núcleos através do uso de fork. Isso porque o fork cria um novo processo, independente do pai, com sua própria memória, seu próprio GIL e sua própria thread principal. Como cada processo é isolado, o sistema operacional pode executá-los em paralelo real, os distribuindo entre os núcleos da CPU.
Vamos mudar para ruby padrão usando rbenv
rbenv global 3.3.5
ruby --version
Saída
ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
Vamos executar o programa usando fork
require 'benchmark'
NUM_PROCESSES = 4
WORK_PER_PROCESS = 100_000_000
def trabalho_pesado
total = 0
WORK_PER_PROCESS.times do |i|
total += Math.sqrt(i)
end
total
end
puts "Iniciando benchmark com #{NUM_PROCESSES} processos (fork)..."
tempo = Benchmark.realtime do
pids = []
NUM_PROCESSES.times do |i|
pid = fork do
puts "[Filho ##{i}] PID: #{Process.pid}, Pai: #{Process.ppid}"
trabalho_pesado
exit!
end
pids << pid
end
pids.each { |pid| Process.wait(pid) }
end
puts "Tempo total: #{tempo.round(2)} segundos"
Saída
[Filho #0] PID: 2881532, Pai: 2881489
[Filho #1] PID: 2881535, Pai: 2881489
[Filho #2] PID: 2881538, Pai: 2881489
[Filho #3] PID: 2881541, Pai: 2881489
Tempo total: 8.74 segundos
No final esse foi o resultado dos nossos testes
| Teste | Interpretador | Abordagem | Tempo |
|---|---|---|---|
| Teste 1 | MRI | Threads | 34.12 s |
| Teste 2 | JRuby | Threads | 13.48 s |
| Teste 3 | MRI | Fork | 8.74 s |
Teste 3 foi ~3,9 vezes mais rápido e teve um ganho de ~74,4% sobre o Teste 1 e ~1,5 vezes mais rápido e teve um ganho de ~35,2% sobre o Teste 2.
Race condition
Agora vamos falar sobre um problema bastante comum quando tratamos de concorrência, o race condition. Sabemos que as threads são executadas de forma concorrente, mas como não controlamos a ordem em que elas são executadas, isso fica a cargo do escalonador preemptivo do sistema operacional. Ou seja, quando executamos uma tarefa com múltiplas threads que dependem da ordem de execução, temos o risco de enfrentar uma race condition. Para exemplificar, vamos rodar o código abaixo usando o Ruby padrão (MRI) e o JRuby, assim como nos exemplos anteriores. O programa cria 10 threads e cada uma incrementa a variável contador 1000 vezes. Esperamos que o valor final seja 10000.
contador = 0
threads = 10.times.map do
Thread.new do
1000.times do
contador += 1
end
end
end
threads.each(&:join)
puts "O valor final deve ser 10000"
puts "Valor final do contador: #{contador}"
Saída usando MRI (Versão do ruby 3.3.5)
O valor final deve ser 10000
Valor final do contador: 10000
Saída usando JRuby (Versão jruby-9.4.8.0)
O valor final deve ser 10000
Valor final do contador: 9451
Perceba que a saída com JRuby não retornou a contagem de 10000 e sim 9451, executando outra vez:
O valor final deve ser 10000
Valor final do contador: 8800
No MRI (CRuby), mesmo utilizando múltiplas threads nativas do sistema operacional, existe um bloqueio global chamado GVL (Global VM Lock) que garante que apenas uma thread execute código Ruby por vez na CPU, evitando assim condições de corrida (race conditions) em operações concorrentes sobre variáveis compartilhadas. Esse lock global limita o paralelismo de CPU, liberando-o apenas em operações de I/O ou chamadas de código nativo, o que explica por que o exemplo com múltiplas threads incrementando uma variável compartilhada sempre retorna o valor correto no MRI, ao contrário do que acontece em outras implementações como JRuby que não possuem esse bloqueio global.
Conclusão
Ruby é realmente fantástico, não é? Ele conta com gems (Gem são as bibliotecas de ruby) especializadas para paralelismo, como a gem parallel, que facilita o uso de múltiplos processos. Além disso, Ruby oferece APIs nativas para a criação de threads, que funcionam muito bem em tarefas de I/O concorrente. É importante lembrar que criar múltiplas threads ou usar fork pode aumentar a complexidade no gerenciamento dos recursos e do fluxo do programa, exigindo cuidado na implementação. Ou seja, não existe uma bala de prata para todas as situações, pois a melhor abordagem depende do contexto e dos objetivos do projeto. Por aqui aprendemos como Ruby lida com processos forkados e threads, a comunicação entre processos e entendemos o risco das race conditions, que acontecem quando recursos compartilhados são acessados sem a devida sincronização.
Referências
https://concorrencia101.leandronsp.com/
https://www.toptal.com/ruby/ruby-concurrency-and-parallelism-a-practical-primer
https://apidock.com/ruby/Process/fork/class