Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Parallel Programming

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for Ghina Ajjour Ghina Ajjour
December 13, 2012
98

Parallel Programming

Avatar for Ghina Ajjour

Ghina Ajjour

December 13, 2012
Tweet

Transcript

  1. Outline • Simple threading • Race conditions • Modern threading

    • GIL • Handling deadlocks • Conclusion
  2. Simple threading • A process is created when ruby, rails,

    or irb is executed. • Within each process, there is something that which is executing the code in the process Thread
  3. Simple threading • “Main” thread • Call Thread.new to create

    as many threads as you want • Once a block of code finishes executing a thread is dead • If the main thread exists the process dies.
  4. Race conditions • Generally a computer executes one thread per

    core • A dual core CPU can execute two threads at the same time • Now lets parallelize the example above.
  5. Race conditions • Anytime two threads try to change the

    same variable, they have potentials for race conditions • The expected value of I is 2,000,000 but the actual value is 1,330,864 this is because of race condition
  6. Thread Safety • Mutation of shared state must be done

    atomically. • Any time a variable is changed that is shared by many threads, it needs to be done atomically. • Ruby gives one tool to do so : the lock aka the mutex. • Mutex = Mutual exclusion = only one thread can be executing this code at a time
  7. • Mutex effectively makes the increment atomic. • Threads have

    such a terrible reputation because locks are very painful to use in practice Thread Safety
  8. Modern threading • Atomic Instructions • Transactional Memory (STM) •

    Actors – the preferred method • Locks exponentially grow the complexity of your code base • For Rubyists avoid Thread.new
  9. GIL – Global Interpreter lock • Is a mutual exclusion

    lock • There is always one GIL for each interpreter process • Only allows one thread to run at a time • Limits the amount of parallelism reachable through concurrency of a single interpreter process with multiple threads • Ruby GIL only applies to non I/O operations
  10. Dead Lock • Deadlock is the condition that occurs when

    all threads are waiting to acquire a resource held by another thread
  11. Conclusion • There are many ways to avoid/solve race conditions,

    each may be used according to its pros and cons