Como o Celluloid traz concorrência para o Ruby

Celluloid
Atores, concorrência e relevância para o mundo Ruby

@dodecaphonic
Sou @dodecaphonic no Twitter. Fico com essa cara quando o computador não faz o que eu mando.

̶ Todo post no Hacker News desde 2005
"Ruby já era. Não tem como uma
linguagem com x sobreviver em um
mundo precisando de y."

VÁRIOS X E
VÁRIOS Y
X - tipos dinâmicos; Y - software complexo
X - execução lenta; Y - software complexo/em escala
X - metaprogramação em runtime; Y - software complexo
X - ausência de concorrência; Y - software complexo

CONCORRÊNCIA
NÃO É
PARALELISMO
Concorrência é a possibilidade de executar duas tarefas que se completarão em períodos que se sobrepõem. Isso não significa que as duas tarefas vão
executar ao mesmo tempo — isso aí é paralelismo. Você pode ter concorrência até em máquinas single-threaded.

MAS EM RUBY TUDO
É LINDO E FOFO!
Não. Esta é uma área em que Ruby está bem defasado em relação a outras linguagens mais modernas/projetadas com isso em mente.

MRI E SUA TRAVA
GLOBAL (GIL)
Em Ruby a gente TEM concorrência — tem uma classe Thread, afinal. Mas é justamente aí onde a trava global do interpretador do Matz, a GIL, atrapalha
a história de concorrência no Ruby. Você pode ter concorrência, mas não paralelismo (com a exceção do IO).

TER UMA TRAVA
GLOBAL É BOM?
Algumas pessoas (inclusive o ruby-core) consideram a GIL uma funcionalidade fofa dessas, que reduz certas classes de bugs clássicos de threading. Mas
olha o custo: meu código roda, mas roda lento, não aproveita a máquina.

‒Yukihiro Matsumoto
"I don't consider myself as the
threading guy."
E a solução para isso não vai vir da cabeça do Matz. Ele não se considera apto a resolver o problema. MINASWAN - MINCSWCN.

O que é que Threads
oferecem, aﬁnal?
- Threads são contextos de execução que ficam subordinados a um processo do SO. Eles dividem o mesmo espaço de memória, ao contrário de
processos;
- Cada Thread pode, potencialmente, ser executado em paralelo pelo seu SO
- A troca de contexto entre Threads é mais rápida do que em Processos

THREADS
PROCESSOS
vs
Processos e Threads podem atingir os mesmos objetivos. Threads têm como vantagens consumir menos recursos e dividir o mesmo espaço de memória.
Processos não exigem que você mude seu jeito de programar significativamente.

DESPERDÍCIO É FEIO
Ou desperdiçaremos por não usarmos nenhum tipo de paralelismo, ou desperdiçaremos por usarmos processos e jogarmos fora memória, inserirmos
latência na comunicação interna, etc.

Escreveu, não leu, e lá vem alguém dizer que programar com threads é difícil, até perigoso.

MutexMonitor Condition Variable
Thread-safe
Race condition
Deadlock
No Ruby, como em outras linguagens, as preocupações são as mesmas. Os problemas principais são os mesmos.

# From: Working With Ruby Threads
Order = Struct.new(:amount, :status) do
def pending?
status == 'pending'
end
!
def collect_payment
puts "Collecting payment..."
self.status = 'paid'
end
end
!
order = Order.new(100.00, 'pending')
!
5.times.map do
Thread.new do
if order.pending?
order.collect_payment
end
end
end.each(&:join)
Vamos usar um programinha que coleta pagamentos de pedidos.

$ ruby race.rb
Collecting payment...
$ ruby race.rb
$ ruby race.rb
$ ruby race.rb

$ ruby race.rb
$ ruby race.rb
$ ruby race.rb
$ ruby race.rb
WTF?

MUTEXES
Mutex - Mutual Exclusion, exclusão múltipla

shared_data = []
!
10.times.map do
Thread.new do
1000.times do
shared_data << nil
end
end
end.map(&:join)
!
puts shared_data.size
require "thread"
!
shared_data = []
mutex = Mutex.new
!
10.times.map do
Thread.new do
1000.times do
mutex.synchronize {
shared_data << nil
}
end
end
end.map(&:join)
!
puts shared_data.size
Sem Mutex Com Mutex

$ ruby array_append_no_mutex.rb
10000
$ chruby jruby
$ ruby array_append_no_mutex.rb
ConcurrencyError: Detected invalid array contents due to
unsynchronized modifications with concurrent users
<< at org/jruby/RubyArray.java:1147
(root) at array_append_no_mutex.rb:6
times at org/jruby/RubyFixnum.java:275
(root) at array_append_no_mutex.rb:5
Sem Mutex
O MRI dá a resposta que a gente espera, por conta da trava global do interpretador. A JVM nem deixa isso rodar, esse despautério.

$ ruby array_append_mutex.rb
10000
rubyonrio_mar14_celluloid/examples
$ chruby jruby
rubyonrio_mar14_celluloid/examples
$ ruby array_append_mutex.rb
10000
Com Mutex
Com o Mutex no lugar, tudo certo.

2
1 A
B
Threads Locks (Mutexes)

A gente não vai ﬁcar muito
mais inteligente. O jeito é
pensar em outras maneiras de
resolver o problema.

Software Transactional Memory
(Clojure)
Communicating Sequential Processes
(go, core.async do Clojure)
Actors
(Erlang, Akka, Celluloid)
Três grandes ideias (não as únicas) e linguagens/bibliotecas em que elas estão proeminentemente implementadas.

ACTORS
Mas primeiro, uma breve explicação do Actor Model.

1973
Em 1973, Carl Hewitt et al bolaram uma visão computacional para um mundo em que computadores teriam dezenas, centenas, milhares de unidades de
processamento independentes. Há 41 anos eles sabiam claramente daquilo que nós aqui no Ruby tentamos ignorar.

ERLANG
Graças, em grande parte, ao Erlang, o modelo ficou bastante conhecido e as ideias geradas há quarenta anos passaram a povoar as mentes
contemporâneas.

Mr. Red Actor
1973 Memory Ln.
Boston, MA
Um ator é uma entidade computacional que se comunica com outras por meio de mensagens. Cada ator é completamente independente do outro.

Mr. Red Actor
1973 Memory Ln.
Boston, MA
Eles só podem se comunicar usando o endereço da caixa de mensagens do ator. Não dá pra puxar o outro ator pelo braço e mandar ele fazer alguma
coisa.

Mr. Red Actor
1973 Memory Ln.
Boston, MA
Da mesma maneira, o recipiente não sabe nada sobre quem mandou a mensagem: só interessa a mensagem em si. Esse desacoplamento entre as partes
é uma ideia extremamente poderosa.

No modelo, as mensagens são enviadas de maneira assíncrona, em um esquema fire-and-forget. Não há garantia da ordem em que serão processadas.

‒Tony Arcieri, criador do Celluloid
“… at the very least Celluloid puts
threads on Rails.
!
It makes it a lot easier to get right
prototypes and get them done
quickly and not spend a lot of time
debugging all this stuff in the
standard library.”
Em uma entrevista com o rubista Jesse Storimer, o criador do Celluloid, Tony Arcieri, disse que gosta de pensar que o Celluloid é uma espécie de Threads
on Rails.

ATORES QUE SÃO
OBJETOS, OBJETOS
QUE SÃO ATORES
O Celluloid dá uma cara Ruby ao modelo de atores. Isso quer dizer que seu programa não vai ficar subitamente com outra cara, seguindo outros
paradigmas, como quando se usa o EventMachine.

class ChocolateCake
include Celluloid
!
def lose_slice
sleep 2
puts "Lost slice"
end
end
Esta é a cara de um ator no Celluloid. A única coisa que precisa ser colocada é esse “include Celluloid”. A partir desse momento seu objeto é concorrente
e está em seu próprio Thread.

BEIJINHO NO OMBRO
PROS DEADLOCKS
Celluloid uses a concurrent object model which combines method dispatch and thread synchronization. Each actor is a concurrent object running in its
own thread, and every method invocation is wrapped in a fiber that can be suspended whenever it calls out to other actors, and resumed when the
response is available. This means methods which are waiting for responses from other actors, external messages, or other system events (including I/O
with Celluloid::IO) .

TOLERÂNCIA A
FALHAS
Inspirado pelo Erlang, o Celluloid segue a filosofia “let it crash”, permitindo que você estabeleça relações entre atores que determinem como o sistema
deve se portar em caso de falhas.

TOLERÂNCIA A
FALHAS
Links
O primeiro método é o link. Um ator se liga a outro, e seus destinos estão selados. (demo no pry)

TOLERÂNCIA A
FALHAS
Links Supervisores
Inspirado pelo Erlang, o Celluloid segue a filosofia “let it crash”, permitindo que você estabeleça relações entre atores que determinem como o sistema
deve se portar em caso de falhas.

COMPUTAÇÃO
DISTRIBUÍDA
(via DCell)
A partir do momento que atores não estão ligados diretamente e só têm os endereços uns dos outros, um ator pode estar na mesma máquina ou não. O
modelo de programação não muda.

IO ASSÍNCRONO
COM ATORES
(via Celluloid::IO)
TOMA ESSA, NODE!

• http://github.com/celluloid/celluloid
• http://github.com/dodecaphonic/balladina

• http://www.ﬂickr.com/photos/
zigazou76/3702501888/in/photostream/ (Perigo)

Como o Celluloid traz concorrência para o Ruby

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Como o Celluloid traz concorrência para o Ruby

Semelhante a Como o Celluloid traz concorrência para o Ruby (20)

Como o Celluloid traz concorrência para o Ruby