The world of concurrent computation is a complicated one. We have to think about the hardware, the runtime, and even choose between half a dozen different models and primitives: fork/wait, threads, shared memory, message passing, semaphores, and transactions just to name a few. And that's only the beginning.
What's the state of the art for dealing with concurrency & parallelism in Ruby? We'll take a quick look at the available runtimes, what they offer, and their limitations. Then, we'll dive into the concurrency models and ask are threads really the best we can do to design, model, and test our software? What are the alternatives, and is Ruby the right language to tackle these problems?
Spoiler: out with the threads. Seriously.
10. if(cond1 && cond2) { System.err.println("Am I faster yet?"); } if (cond1 || cond2) { System.err.println("Am I fast yet?"); } 1 2 Turns out. We don’t know. A quick poll which is faster?
11. Hardware Parallelism Software Parallelism (Processes, Threads, Events) pthreads, lwkt, epoll, kqueue, … C / C++, Java, Ruby, …. The “concurrency API” a bolt-on systems component for any language
12. Bruce: if you could go back in time, what is the one thing you would change? Matz: “I would remove the thread and add actors or some other more advanced concurrency features” More advanced concurrency features?
31. No mutexes, no semaphoresCSP / Pi-calculus The 50k foot view…
32. A Multiple workers can share a channel A Workers are mobile! Delegate the channel to someone else! C(A) A A(B) Send a “response” channel to another process! B
34. Named channel Typed channel c =Agent::Channel.new(name: 'incr', type: Integer) go(c) do |c, i=0| loop { c <<i+= 1 } end p c.receive# => 1 p c.receive# => 2 Spawn the worker Consume the results Producer / Consumer look, no threads!