9. Not all programmers agree on the meaning of the
terms 'parallelism' and 'concurrency'. They may
define them in different ways or do not distinguish
them at all.
11. Concurrency is about dealing with lots of things at
once.
Parallelism is about doing lots of things at once.
http://blog.golang.org/concurrency-is-not-parallelism
Rob Pike
25. Pros
• No need to worry about scheduling (preemptive)
• Commonly used
• Wide language support
Cons
• Scheduling overhead (context switching)
• Synchronization/locking issues
Mutex
29. Pros
• Increased concurrency
• No thread needs to wait for access to a resource
• Smaller scope that needs synchronizing - modifying disjoint parts of a
data structure
STM's benefits
http://www.haskell.org/haskellwiki/Software_transactional_memory
Cons
• Aborting transactions
• Places limitations on the behavior of transactions - they cannot perform
any operation that cannot be undone, including most I/O.
Transactional Memory
31. How do we handle atomicity? Don't share memory.
How to communicate?
IPC
32. Pros
• Can't corrupt data when data is not shared.
• No locking.
• Easier to scale horizontally (adding nodes).
Cons
• Can't communicate over shared memory
• Slower to spawn a new process
• More memory overhead.
• Scaling horizontally is expensive.
IPC
34. Pros
• Uses message passing and channels heavily, alternative to
locks
Cons
• Handling very big messages, or a lot of messages,
unbounded buffers
• Messaging is essentially a copy of shared
CSP
36. Atomicity? Conflict? Every actor has it's own address space.
Don't share memory. Communicate via mailboxes.
Actors
37. Comparison with CSP
• CSP processes are anonymous, while actors have
identities.
• Message-passing in actor systems is fundamentally
asynchronous (CSP traditionally uses synchronous
messaging: "rendezvous")
• CSP uses explicit channels for message passing,
whereas actor systems transmit messages to named
destination actors.
Actors
38. Pros
• Uses message passing and channels heavily
• No shared state (avoid locks, easier to scale)
• Easier to maintain the code
Cons
• When shared state is required doesn't fit as well
• Handling very big messages, or a lot of messages
• Messaging is essentially a copy of shared data
Actors
41. A Curious Course on Coroutines and Concurrency:
David Beazley (https://twitter.com/dabeaz) writing an operating system
with only coroutines.
http://dabeaz.com/coroutines/
No Threads, Evented style, just cooperative scheduling of coroutines...
Possible use cases:
http://stackoverflow.com/questions/303760/what-are-use-cases-for-a-
coroutine
Fibers
42. Pros
• Expressive state: state based computations much easier
to understand and implement
• No need for locks (cooperative scheduling)
• Scales vertically (add more cpu)
Cons
• Single thread: Harder to parallelize/scale horizontally
(use more cores, add more nodes)
• Constrained to have all the components work together
symbiotically
Fibers
44. Examples
• C10k problem
• Eventmachine in ruby
• Twisted in python
• Redis's event loop
• Apache vs Nginx
• Node.js vs the world
Eventmachine
45. Eventmachine
“Evented servers are really good for very light requests, but
if you have a long-running request, it falls down on its face”
Technically, valid, but in practice, not necessarily true.
46. Eventmachine
Reactor:
• wait for event (Reactor job)
• dispatch "Ready-to-Read" event to user handler (Reactor job)
• read data (user handler job)
• process data ( user handler job)
Proactor:
• wait for event (Proactor job)
• read data (now Proactor job)
• dispatch "Read-Completed" event to user handler (Proactor job)
• process data (user handler job)
47. Pros
• Avoid polling. CPU bound vs IO bound
• Expanding your horizons (very different paradigms)
• Scales well vs spawning many threads
Cons
• You block the event loop, all goes bad
• Program flow is "spaghetti"-ish
• Callback Hell
• Hard to debug, you loose "the stack”
Eventmachine
