Slides for my talk at RubyConf India 2013

1. CONCURRENCY
&
RUBY
Rocky Jaiswal
RubyConf India 2013

2. WHY CONCURRENCY?

3. ABOUT ME
Learning programming for the last 11 years
Did Java for around 8 years
Started learning Ruby ~3 years back
♥ Ruby
♥ the Ruby community
Also learning some CoffeeScript and Scala
http://rockyj.in
@whatsuprocky

4. CONCURRENCY?
Concurrency is when two tasks can start, run, and
complete in overlapping time periods
Concurrency can be implemented even in single
processing units to speed things up
Concurrency is non-deterministic
Whereas a parallel program is one that merely runs on
multiple processors, with the goal of hopefully running
faster than it would on a single CPU

5. THREADS VS PROCESSESS
Threads are light weight processes that run in the same
memory context
Ruby has Green Threads which are managed by the Ruby
process
JRuby has real OS thread that run parallel to the parent
thread

6. THREADS IN RUBY

7. SAMPLE UNICORN SETUP
15 Unicorns = 15 Processes
1 Unicorn Process ~= 150 MB
15 Processes ~= 2 GB RAM*
Scaling this means more processes = more memory =
more money
Also, If you are CPU bound you want to use no more
unicorn processes than you have cores, otherwise you
overload the system and slow down the scheduler.

8. CONCURRENCY IS GOOD
JRuby + Puma / Torquebox
High-Scalability with less memory
Resque / Sidekiq
More workers and faster processing with less memory

9. SO IS IT ALL DOOM AND GLOOM?
No!
Most Rails applications are IO bound
With MRI you are always thread safe
MRI is getting faster and GC is getting better
Processes management is optimized
Passenger is using a hybrid - evented + threaded /
process architecture

10. THREAD-SAFETY
LET ME GIVE YOU A DEMO
Appending to Arrays:
MRI Version
vs
JRuby Version
DEMO

11. RUN CODE ON MRI & JRUBY
array = []
5.times.map do
Thread.new do #Init 5 threads
1000.times do
array << nil #In each thread add 1000 elements to the Ar
end
end
end.each(&:join)
puts array.size

12. EVEN APPENDING TO ARRAYS IS
NOT THREAD SAFE!

13. WHAT ABOUT RAILS
config.threadsafe!
def threadsafe!
@preload_frameworks = true
@cache_classes = true
@dependency_loading = false
@allow_concurrency = true
self
end

14. JRUBY ON RAILS
DEMO

15. BAD COUNTER CODE
class PagesController < ApplicationController
@counter = 0
class << self
attr_accessor :counter
end
#Classic read-modify-write problem
def index
counter = self.class.counter # read
sleep(0.1)
counter += 1 #update
sleep(0.1)
self.class.counter = counter # write
users = User.all
puts "-----------" + self.class.counter.to_s + "------------"
end
end

16. UGLY SYNCHRONIZED CODE
class PagesController < ApplicationController
@counter = 0
@semaphore = Mutex.new
class << self
attr_accessor :counter
attr_accessor :semaphore
end
def index
#counter = self.class.counter # read
sleep(0.1)
self.class.semaphore.synchronize {
self.class.counter += 1 #update
}
sleep(0.1)
#self.class.counter = counter # write
users = User.all
puts "-----------" + self.class.counter.to_s + "------------"
end
end

17. RAILS 4 IS CONCURRENCY
ENABLED BY DEFAULT

18. CONCURRENCY INTRODUCES
Race Conditions
Deadlocks
Starvation
etc.
BUT GIVES YOU
Speed
Less Memory Usage

19. SAFE CONCURRENCY
Don't do it.
If you must do it, don't share data across
threads.
If you must share data across threads, don't
share mutable data.
If you must share mutable data across threads,
synchronize access to that data.

20. THREAD SAFETY IN JRUBY
LOCKS
ATOMICITY
IMMUTABILITY

21. ATOMIC COUNTER
java_import 'java.util.concurrent.atomic.AtomicInteger'
class PagesController < ApplicationController
@counter = AtomicInteger.new(1)
class << self
attr_accessor :counter
end
def index
sleep(0.1)
counter = self.class.counter.getAndIncrement() #update
sleep(0.1)
users = User.all
puts "-----------------" + counter.to_s + "-----------------"
end
end

22. ALL THIS SUCKS!
95% of syncronized code is broken. The other 5% is
written by Brian Goetz. - Venkat Subramaniam

23. ENTER ACTOR

24. THE ACTOR MODEL
Introduced by Carl Hewitt in 1973
Contributions by a lot of scholars and universities
Popularized by Erlang, now in Scala
Simple and high-level abstractions for concurrency and
parallelism
Objects are Actors each with their own state which is never
shared
Communication happens through messages
Very lightweight event-driven processes (approximately 2.7
million actors per GB RAM [Akka])

25. THE ACTOR MODEL -2
Easier to deal with humans than with threads
Like humans, Actors communicate via messages
No state sharing, communicate via immutable messages

26. IMPLEMENTATIONS

27. PRODUCER CONSUMER PROBLEM
Demo with JRuby + Locks
Demo with JRuby + Celluloid

28. PRODUCER CONSUMER
with locks
HTTPS://GIST.GITHUB.COM/ROCKY-
JAISWAL/5847810

29. PRODUCER CONSUMER
with actors
HTTPS://GIST.GITHUB.COM/ROCKY-
JAISWAL/5847814

30. SUMMARY
Concurrency is the need of the hour
MRI is thread safe by default due to GIL / GVL
JRuby gives you real concurrency (RBX as well)
With power comes responsibility
Don't worry, concurrency can be easy if you follow the
ground rules
If you want to write concurrent code yourself, use
Actors
* I did not cover STM (provided by Clojure)

31. THANK YOU!
QUESTIONS
#A lot of this content has been taken from blogs, wikis and books. I do not claim it is my
own and I wholeheartedly thank everyone who helped me with this presentation.