Celluloid - Atores, concorrência e relevância para o mundo Ruby
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 165 views

Uma apresentação sobre a biblioteca Celluloid, que traz o modelo de computação baseado em atores ao universo Ruby.

Uma apresentação sobre a biblioteca Celluloid, que traz o modelo de computação baseado em atores ao universo Ruby.

Statistics

Views

Total Views
165
Views on SlideShare
165
Embed Views
0

Actions

Likes
1
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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, 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 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 Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment...
  • $ ruby race.rb Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting payment... Collecting payment... Collecting payment... Collecting payment... $ ruby race.rb Collecting 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 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.
  • 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" 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!
  • "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)