In this presentation titled "Parallel Processing With Ruby," delivered at RubyConf MY 2017 by Dilum Navanjana, the discussion revolves around the intricacies of parallel processing and concurrency within Ruby programming. Navanjana begins by explaining the fundamental difference between parallel processing, where multiple threads can run simultaneously, and concurrency, which allows multiple threads to exist but not simultaneously execute. He points out that Ruby MRI (Matz's Ruby Interpreter) does not support true parallel processing due to its Global Interpreter Lock (GIL), which effectively restricts execution to a single thread at a time.

Key Points Discussed:

• Concurrence vs. Parallel Processing: Navanjana defines the two concepts, emphasizing that Ruby MRI supports concurrency but not parallelism, leading to most applications only utilizing one CPU while others remain idle.

• Ruby Implementations: Different Ruby implementations like JRuby and Rubinius support both concurrency and parallelism, while MRI distinguishes itself with its green threads and GIL, which affects thread management and execution.

• Potential Issues with Shared Mutable Data: The speaker highlights the risks associated with mutable shared data in multi-threaded environments, illustrating this using a code example. Here, an array is concurrently accessed by multiple threads, which could lead to incorrect results without proper synchronization mechanisms like mutexes.

• Implementation of Mutex: He introduces the concept of mutexes as a solution for the problems arising from shared mutable data, ensuring that only one thread can operate on a segment of code at any given time.

• Upcoming Features in Ruby 3: Navanjana discusses proposals for Ruby 3, notably the implementation of 'Guilds', which aims to enhance concurrency and potentially replace GIL, allowing for more efficient processing across multiple threads.

• Fiber vs. Threads: The presentation also touches on fibers as lightweight alternatives to threads for concurrent programming, mentioning how they can be utilized effectively in Ruby.

• Celluloid and Actor Models: An overview of the Celluloid gem is provided, where interactions between threads are modeled as actors communicating through mailboxes, thus streamlining concurrency.

Conclusions:

Navanjana concludes by emphasizing that while Ruby MRI can be thread-safe, developers must be mindful of how they handle shared mutable data. The presentation encourages leveraging mutexes or considering moving to other Ruby implementations that support safe parallel processing where necessary. The advancement with Ruby 3 promises improvements that could significantly modernize how concurrency and parallelism are handled, opening up opportunities for more resource-efficient application development.