Real World Concurrency

The best way to explain concurrency is to compare the different types of concurrent systems that may be found in downtown NYC during a weekday.

Parallelism:
Cars driving down the street next to each other in their own respective lanes demonstrates a parallel concurrent system. The potential parallelism and efficiency that can occur in this system depends on a few significant properties of the current state of environment, specifically;
1. Where the cars are going?
2. How Congested is the traffic?
3. How attentive, polite and in sync is the driver with those around him?
4. How many available parking spaces are there in areas of contention?

The environment is considered an embarrassingly parallel environment if all the drivers
are headed toward their work's individually assigned parking lot space while taking a back road they know will most likely have little traffic during that time of day based on driving conditions information one of the drivers shared with the group.

On the contrary, this parallel system can be very chaotic and inefficient when traffic is packed and car horns are blaring because 10 vehicles are trying to squeeze in and cut each other off so they can take the parking space that is currently being unsuccessfully vacated by a now boxed in car.

Preemptively Scheduled Threads:

This model is best visualized as a set of cars going from point A to point B while hitting a bunch of 4 way intersections on the way. When a car is driving and it approaches a light that just turned red this is called a preemption interrupt. The car driving (func Car.Drive(a, b point)) is forced to stop and the intersecting lane's traffic signal turns green and the cars waiting on this light are allowed to resume driving.

The important point to take away from this system is that the cars resume from their previous location they were at between point A and B when preempted in their Drive() methods. Which relates to our real world example because if our cars are stopped at the second intersection, they should logically resume driving at the second intersection when the signal turns green.

Communicating Sequential Processes:

This model is best represented by the set of people that exist within the current environment context. Whether they are driving cars down the street, walking to work, dining out with their significant other, it doesn't matter because we are looking at the entire system of people as processes with their own unique mind and tasks.

As far as the individual people are concerned, they might as well be the only people on the street because they are only concerned with their current task and agendas. For example lets say we have a CSP person named Bob who is currently late for work. He doesn't need to be concerned with the couple eating dinner across the street if his only priority is to get to work ASAP.

However when Bob wants to cross the street, he needs to check and make sure its safe to cross the street. If it isn't, then he needs to try and communicate his existence with the drivers that could possibly run him over by accident as he runs across the street.

This concurrent system is very organic.

Actor Model:

This system is a lot like the communicating sequential processes model except communicating messages between actors isn't synchronized communication.

The actor model is best described as an office building with multiple floors of employees (actors) who each have a message passing air tube connected to a central autonomous message sorting system. An employee can only send a message to another employee if he knows their desk number and messages may not arrive at an employee in the order they were sent out if the actor model implementation doesn't pipeline the messages. From the employee's point of view there is no way to check whether or not a message was received in a FIFO manner.

When an employee receives a message, and depending on the contents of that message; an employee may dispatch messages, hire new employees, or plan ahead the way they will handle the next message. The main difference between the Actor Model and CSP is that an actor transmits messages to a specific actor by sending to the actor's address that must be known to the sending actor. Communicating sequential processes on the other hand are anonymous and may (or rather should) only communicate with other processes by sending information directly to the processes it shares a communication channel with.

The actor model is inherently concurrent by design and is very capable of running in parallel.

Concurrency:
In Rob Pike's talk about "Concurrency is not Parallelism.", the overall point that Rob was trying to make in my opinion is that Concurrency is too often mistakenly understood and explained as if it was a synonym for parallelism. The idea that a concurrent system is a system where all processes are executing either literally in parallel or multiplexed on a single thread to simulate executing in parallel. This is not correctly describing concurrency because there are examples of concurrency that are not trying to simulate parallelism at all.

In the preemption example I describe a concurrent system that isn't really parallel by design but rather has a "heave and hoe" kind of execution flow. However, there is a way to make this model benefit from parallelism and that's by creating another instance of cars to start from Point A and make them travel to Point B one intersection behind the previous car. We could even take in one more step further and double our potential parallelism by putting two cars at a time riding next to each other in an embarrassingly parallel way.

 This is the example that should really begin to shed light on what a concurrent system actually is for those trying to understand the difference between parallelism and concurrency. The truth is concurrency is not parallelism but every system that runs in parallel IS concurrent.

 Parallelism is a mode of execution, concurrency is a model of isolated programming contexts.