DEV Community: Michael Alves

Implementando um Sistema de Ranking com Rating Elo em Ruby

Michael Alves — Wed, 17 Jun 2026 17:45:10 +0000

Rating Elo e o filme A Rede Social

Um dos filmes que me fez querer entrar na área de tecnologia foi A Rede Social. O filme conta a história de como Mark Zuckerberg fundou o Facebook, eu descobri várias coisas legais com esse filme. A primeira delas foi que o melhor amigo do Mark era um brasileiro chamado Eduardo e esse brasileiro processou o Mark depois por ter perdido suas ações na empresa. A segunda coisa é que, antes do Facebook, dois irmãos tiveram a ideia de uma rede social para pessoas de Harvard, chamaram o Mark para desenvolver e, depois, esses dois caras também acabaram processando o Mark por plágio, Entre outras coisas, é um ótimo filme, com uma boa trilha sonora.

Nesse filme o Mark briga com a namorada, enche a cara de álcool e decide ter uma ideia bem canalha, que é hackear os Facebooks de Havard (Os Facebooks de Harvard eram diretórios digitais que consistiam em catálogos com as fotos, nomes, cursos e interesses dos calouros), pegar as imagens com os rostos das alunas e fazer um site onde ele compara qual aluna era "mais atraente" (Sim, isso foi bem bizarro e escroto). Nesse momento, ele pede ao seu amigo Eduardo para explicar qual algoritmo usar para fazer o ranking dessas garotas. Nesse caso, era o algoritmo que o Eduardo usava para ranquear os jogadores de xadrez. Daí temos a lendária cena da janela do quarto do Mark contendo a equação usada para gerar o ranking.

Tirando o fato de que essa equação foi usada para o mal, eu fiquei pensando se ela era real e por que foi usada para aquela finalidade de ranking.

Eu pedi para a IA ajustar a imagem para trazer com mais clareza a equação usada.

Apesar da imagem ter o expoente parecendo uma fração, a equação seria esta:

Pesquisando, eu descobri que isso se chama Rating Elo. Segundo a Wikipédia:

O Rating Elo é um método estatístico utilizado para calcular a força relativa entre jogadores de xadrez, inventado pelo físico americano Arpad Elo e utilizado no ranking da FIDE. O método funciona adequadamente quando utilizado da maneira que foi projetado, embora existam algumas limitações. O rating também foi adaptado para outros esportes, como, por exemplo, o tênis.

Porque usar essa equação para ranquear?

É uma boa pergunta. Vamos criar um modelo mental para visualizar melhor o problema. Digamos que temos que ranquear os melhores jogadores de xadrez.

Acredito que o modelo mental mais simples seria ranquear pelo número de vitórias.

Exemplo:

Jogador	Vitórias
João	20
Maria	18
Pedro	5

À primeira vista, parece justo colocar João em primeiro lugar, já que ele possui mais vitórias.

Mas esse modelo possui um problema: ele considera apenas a quantidade de vitórias, ignorando a força dos adversários enfrentados.

Imagine que:

João venceu 20 partidas contra iniciantes.
Maria venceu 16 iniciantes e 2 mestres.
Pedro venceu 5 mestres.

Nesse cenário, as vitórias não possuem o mesmo valor.

Era esperado que um mestre derrotasse um iniciante, então as 20 vitórias de João trazem pouca informação sobre sua habilidade real. Por outro lado, as 5 vitórias de Pedro contra mestres são resultados muito mais difíceis e inesperados, indicando que ele provavelmente é mais forte do que seu histórico inicial sugere.

O sistema Elo foi criado para resolver exatamente esse problema: em vez de contar apenas quantas partidas cada jogador venceu, ele também considera a força dos adversários derrotados. Dessa forma, vencer um jogador forte vale mais do que vencer um jogador fraco, tornando o ranking muito mais representativo da habilidade real dos participantes.

Vamos implementar a equação

ELO_DIVISOR = 400.00

def rating_elo(rating_player_a, rating_player_b)
  rating_players_result = (rating_player_b - rating_player_a) / ELO_DIVISOR
  1 / (1 + 10**rating_players_result)
end

Explicando cada linha, o ELO_DIVISOR é uma constante em Ruby, usada para indicar que esse valor não deve mudar.

A próxima linha é o nosso método, def rating_elo. Esse método recebe dois parâmetros, que seriam equivalentes ao RA e ao RB.

Na próxima linha (rating_players_result = (rating_player_b - rating_player_a) / ELO_DIVISOR), calculamos a expectativa de pontuação dos jogadores, ou seja, a probabilidade de o jogador A vencer o jogador B.

Exemplo de uso (copie e cole o código no console Ruby, o IRB):

ELO_DIVISOR = 400.00

def rating_elo(rating_player_a, rating_player_b)
  rating_players_result = (rating_player_b - rating_player_a) / ELO_DIVISOR
  1 / (1 + 10**rating_players_result)
end

# Criamos variáveis para definir o rating inicial de cada jogador
rating_player_a = 1500
rating_player_b = 1900

# Usamos o método para calcular a probabilidade de vitória do jogador A
result = rating_elo(rating_player_a, rating_player_b)

# Pegamos apenas duas casas decimais para facilitar o entendimento do resultado
result.round(2)

Resultado da execução:

irb(main):027> rating_player_a = 1500
irb(main):028> rating_player_b = 1900
=> 1900
irb(main):029> result = rating_elo(rating_player_a, rating_player_b)
=> 0.09090909090909091
irb(main):030> result.round(2)
=> 0.09
irb(main):031>

Ou seja, o nosso jogador A tem apenas 9% de chance de ganhar do jogador B. Faz sentido, pois o rating inicial dele é menor.

Se invertermos a ordem, o jogador B terá 91% de chance de vitória.

irb(main):031> result = rating_elo(rating_player_b, rating_player_a)
=> 0.9090909090909091
irb(main):032> result.round(2)
=> 0.91
irb(main):033>

Agora precisamos usar a fórmula Elo e, após isso, calcular o novo rating depois de uma partida. Para isso, precisamos definir o quanto o rating muda ao finalizar uma partida.

Para isso, vamos usar uma constante chamada K_FACTOR. Ela é o parâmetro que controla o quanto o rating vai mudar após uma vitória ou derrota.

Eu vou definir que o nosso K_FACTOR é 90 e também vou criar uma classe para os nossos jogadores, facilitando a atualização do rating.

ELO_DIVISOR = 400.0
K_FACTOR = 90

class Player
  attr_reader :name
  attr_accessor :rating

  def initialize(name, rating)
    @name = name
    @rating = rating
  end
end

Agora precisamos adicionar a lógica do Elo com atualização de rating. Seguindo a lógica de uma partida normal, teremos atualização para vitória, derrota e empate.

def play(player_a_name, player_b_name, score_a)
  # Busca o jogador A no hash de jogadores através do nome
  player_a = @players.fetch(player_a_name)

  # Busca o jogador B no hash de jogadores através do nome
  player_b = @players.fetch(player_b_name)

  # Calcula automaticamente o resultado do jogador B

  # Exemplos:
  # Resultado de A   Resultado de B
  # 1.0 (vitória)   0.0
  # 0.5 (empate)    0.5
  # 0.0 (derrota)   1.0
  score_b = 1.0 - score_a

  # Calcula a expectativa de pontuação de A contra B
  expected_a = rating_elo(player_a, player_b)

  # Calcula a expectativa de B
  expected_b = rating_elo(player_b, player_a)

  # Atualiza o rating dos jogadores
  player_a.rating += K_FACTOR * (score_a - expected_a)
  player_b.rating += K_FACTOR * (score_b - expected_b)
end

Basicamente, com o método play, nós decidimos o vencedor da partida ou se houve empate.

Exemplo de uso:

# Player A vence
ranking.play("Michael", "Angelica", 1.0)

# Empate
ranking.play("Michael", "Angelica", 0.5)

# Player A perde
ranking.play("Michael", "Angelica", 0.0)

Por último, adicionamos um método para trazer o ranking dos jogadores ordenados.

def leaderboard
  @players.values
          .sort { |a, b| b.rating <=> a.rating }
          .each_with_index do |player, index|
    puts "#{index + 1}. #{player.name.ljust(8)} #{player.rating.round(2)}"
  end
end

Agora adicionamos tudo em uma classe chamada Ranking e temos o código completo.

ELO_DIVISOR = 400.0
K_FACTOR = 90

class Player
  attr_reader :name
  attr_accessor :rating

  def initialize(name, rating)
    @name = name
    @rating = rating
  end
end

class Ranking
  def initialize(players)
    @players = {}

    players.each do |name, rating|
      @players[name] = Player.new(name, rating)
    end
  end

  def rating_elo(player_a, player_b)
    1.0 / (1 + 10**((player_b.rating - player_a.rating) / ELO_DIVISOR))
  end

  def play(winner_name, loser_name)
    winner = @players.fetch(winner_name)
    loser = @players.fetch(loser_name)

    expected_winner = rating_elo(winner, loser)
    expected_loser = rating_elo(loser, winner)

    winner.rating += K_FACTOR * (1 - expected_winner)
    loser.rating += K_FACTOR * (0 - expected_loser)

    puts "#{winner.name} venceu #{loser.name}"
    puts "#{winner.name}: #{winner.rating.round(2)}"
    puts "#{loser.name}: #{loser.rating.round(2)}"
  end

  def leaderboard
    @players.values
            .sort_by { |player| -player.rating }
            .each_with_index do |player, index|
      puts "#{index + 1}. #{player.name.ljust(8)} #{player.rating.round(2)}"
    end
  end

  def player(name)
    @players[name]
  end
end

ranking = Ranking.new(
  "Judit"    => 1900,
  "Angelica" => 1800,
  "Michael"  => 1600,
  "Maria"    => 1300,
  "Pedro"    => 1200,
  "Eric"     => 1100
)

Legal, temos a equação funcionando. Agora podemos usá-la na prática para criar um pequeno sistema de ranking.

Ranqueando jogadores

Jogador	Rating inicial
Judit	1900
Angelica	1800
Michael	1600
Maria	1300
Pedro	1200
Eric	1100

Esses são os nossos jogadores. Perceba que a Judit já começa com um rating inicial bem alto, provavelmente porque ela é uma boa jogadora e tem muita experiência. E temos o Eric. Vamos partir do pressuposto de que ele é um jogador promissor, porém teve poucas vitórias.

Rodada 1 — Grande surpresa

Vamos colocar o jogador Eric, último do ranking, para enfrentar o top 3 de jogadores: Judit, Angelica e Michael. E vamos dar a vitória para o Eric.

ranking.play("Eric", "Judit", 1.0)
ranking.play("Eric", "Angelica", 1.0)
ranking.play("Eric", "Michael", 1.0)

O resultado foi:

1. Judit    1810.89
2. Angelica 1712.6
3. Michael  1522.1
4. Eric     1354.41
5. Maria    1300
6. Pedro    1200

O que observar?

Eric ganha muitos pontos.
Judit perde muitos pontos.
Angelica perde muitos pontos.
Michael perde muitos pontos.

Por quê?

Era um resultado extremamente improvável.

Após enfrentar o top 3 e vencer, Eric subiu para a quarta posição do ranking. Ao mesmo tempo que a equação beneficia o jogador que se arrisca e enfrenta os melhores do ranking, ela também pune o jogador de alto nível que perdeu.

Vamos criar outras rodadas para elucidar os conceitos da equação.

Rodada 2 — Resultado esperado

Judit vence Pedro.

ranking.play("Judit", "Pedro", 1.0)

Resultado:

irb(main):067> ranking.leaderboard
1. Judit    1813.49
2. Angelica 1712.6
3. Michael  1522.1
4. Eric     1354.41
5. Maria    1300
6. Pedro    1197.4

O que observar?

Judit ganha poucos pontos.
Pedro perde poucos pontos.

Por quê?

O sistema já esperava que uma jogadora com rating 1810.89 vencesse um jogador com rating 1200.

Rodada 3 — Empate surpreendente

ranking.play("Eric", "Judit", 0.5)

Resultado

irb(main):069> ranking.leaderboard
1. Judit    1774.47
2. Angelica 1712.6
3. Michael  1522.1
4. Eric     1393.43
5. Maria    1300
6. Pedro    1197.4
=>

O que observar?

Eric ganha pontos.
Judit perde pontos.

Mesmo sem vitória.

Por quê?

Empatar contra alguém muito mais forte já é melhor do que o esperado.

Conclusão

O sistema que implementamos aqui é uma versão simplificada do Rating Elo, mas já é suficiente para demonstrar o principal conceito por trás da fórmula: não basta contar vitórias e derrotas, também é necessário considerar a força dos adversários enfrentados.

Na prática, sistemas de ranking costumam ser bem mais sofisticados. Uma possível evolução seria tornar o K_FACTOR dinâmico, fazendo com que ele varie de acordo com o nível ou experiência do jogador. Jogadores novos poderiam ter um fator maior para que o sistema identificasse rapidamente sua habilidade real, enquanto jogadores mais experientes teriam um fator menor, deixando o ranking mais estável.

Outra possibilidade seria considerar o histórico de partidas do jogador. Alguém que mantém uma alta taxa de vitórias ao longo do tempo poderia receber ajustes diferentes de um jogador com desempenho inconsistente. Também poderíamos criar regras específicas para séries de vitórias, frequência de partidas ou até diferentes pesos para torneios.

O objetivo deste artigo não foi construir o sistema de ranking perfeito, mas entender a matemática por trás do Elo e implementar uma versão funcional do algoritmo. A partir daqui, existem diversas formas de aumentar a complexidade do modelo e adaptá-lo para diferentes tipos de jogos e aplicações.

Referências

Rating Elo

The Elo Rating System: A Data-Driven Approach to Ranking Competitor

Concorrência e Paralelismo em Ruby

Michael Alves — Wed, 21 May 2025 22:29:49 +0000

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.akitaonrails.com/2019/03/13/akitando-43-concorrencia-e-paralelismo-parte-1-entendendo-back-end-para-iniciantes-parte-3

https://www.toptal.com/ruby/ruby-concurrency-and-parallelism-a-practical-primer

https://apidock.com/ruby/Process/fork/class

https://www.rubyguides.com/2015/07/ruby-threads/

https://linuxjourney-com.translate.goog/lesson/monitor-processes-ps-command?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt&_x_tr_pto=tc

https://man7.org/linux/man-pages/man2/syscalls.2.html