CelluloidAtores, 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, afinal?

- 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

PROCESSOSvs

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-safeRace 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 ThreadsOrder = Struct.new(:amount, :status) do def pending? status == 'pending' end! def collect_payment puts "Collecting payment..." self.status = 'paid' endend!order = Order.new(100.00, 'pending')!5.times.map do Thread.new do if order.pending? order.collect_payment end endend.each(&:join)

Vamos usar um programinha que coleta pagamentos de pedidos.

$ ruby race.rbCollecting payment...$ ruby race.rbCollecting payment...Collecting payment...Collecting payment...Collecting payment...$ ruby race.rbCollecting payment...Collecting payment...Collecting payment...Collecting payment...$ ruby race.rbCollecting payment...Collecting payment...Collecting payment...

$ ruby race.rbCollecting payment...$ ruby race.rbCollecting payment...Collecting payment...Collecting payment...Collecting payment...$ ruby race.rbCollecting payment...Collecting payment...Collecting payment...Collecting payment...$ ruby race.rbCollecting payment...Collecting payment...Collecting payment...

WTF?

RACE CONDITION

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

1 2 3 4 5

SO

MUTEXES

Mutex - Mutual Exclusion, exclusão múltipla

shared_data = []!10.times.map do Thread.new do 1000.times do shared_data << nil end endend.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 endend.map(&:join)!puts shared_data.size

Sem Mutex Com Mutex

$ ruby array_append_no_mutex.rb10000$ chruby jruby$ ruby array_append_no_mutex.rbConcurrencyError: 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.rb10000rubyonrio_mar14_celluloid/examples$ chruby jrubyrubyonrio_mar14_celluloid/examples$ ruby array_append_mutex.rb10000

Com Mutex

Com o Mutex no lugar, tudo certo.

DEADLOCKS

2

1 A

B

Threads Locks (Mutexes)

2

1 A

B

Threads Locks (Mutexes)

2

1 A

B

Threads Locks (Mutexes)

LIVELOCKS

A gente não vai ficar 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.

Celluloid

‒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" endend

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!

"MAS SÓ ME INTERESSA A

WEB!"

A MORTE DO REQUEST—RESPONSE

BALLADINA

FIM

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

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

• http://www.flickr.com/photos/

zigazou76/3702501888/in/photostream/ (Perigo)