Hello.
Welcome to the first section of this course.
Introduction to go concurrency in this section we're going to see concurrency in the Go language.
We'll learn that with multiple cores and multiple processes.
Applications can help us to achieve better performance and endless possibilities.
We'll look at how to use some of the already known patterns in concurrency safe ways.
Now we move onto the first video of this section that deals with defining concurrency.
In this video we'll first get ourselves introduced to the basic concept of concurrency and then understand
the difference between concurrency and parallelism were also tried to compare communicating sequential
processes that is CSP and Acthar based concurrency the creators of the go language wanted garbage collected
and procedural language it is familiar for newcomers but which at the same time can be used to write
concurrent applications easily and without affecting the core of the language.
The concurrent features of the go language are completely separated from the core language while being
part of it.
A perfect example of abstraction and encapsulation there are many concurrency models in computer science.
The most famous being the actor model present in languages such as Erlang or Scala go on the other side
uses communicating sequential processes or CSP which is a different approach to concurrency.
Many people have misunderstood the differences between concurrency and parallelism even thinking they
are the same.
There is a popular speech by Rob Pyke one of the crates of Go concurrency is not parallelism which I
really agree with.
As a quick summary of the talk we can extract these two points which say that concurrency is about dealing
with many things at once and parallelism is about doing many things at the same time.
Concurrency enables parallelism by designing a correct structure of concurrency work.
For example we can think of the mechanism of a bike when we pedal.
We usually push down the pedal to reduce force and this push raises our opposite leg to the opposite
pedal.
We cannot push with both legs at the same time because the cranks don't allow us to do it.
But this design allows the construction of a parallel bike commonly called a tandem bike a tandem bike
is a bike that two people can ride at the same time.
They both pedal and apply force to the bike in the bike example concurrency is the design of a bike
that with two legs that is go routines you can produce power to move the bike by itself.
The design is concurrent and correct.
If we use a tandem bike and two people.
That is to cause the solution is concurrent correct and parallel.
But the key thing is with a concurrent design we don't have to worry about parallelism because we can
think about it as an extra feature.
If our concurrent design is correct in fact we can use the tandem bike with any one person but the concurrent
design of the legs pedals chain wheels the bike is still correct so to recap it is very important to
keep in mind that concurrency is about structure and parallelism is about execution.
We must think about making our programs concurrent in a better way by breaking them down into smaller
pieces of work and goes -- you know we'll tried to make them parallel if it's possible and allowed
now before we move on to some practical tasks and code.
There is another important concept we have to understand.
We need to have a clear understanding about communicating sequential processes or CSP vs. act based
concurrency the most common and perhaps intuitive way to think about concurrency is close to the way
the actor model works in the actor model.
In fact no one wants to communicate with actor to an actor one must know actor to first for example.
It must have its process I.D. may maybe from the creation step and put a message on its inbox.
Q After placing the message Actor 1 can continue its tasks without getting blocked.
If ACTOR 2 cannot process the message immediately CSP on the other side introduces a new entity into
the equation channels channels are a way to communicate between processes because they are completely
anonymous.
In the case of CSP we don't have a process I.D. to use to communicate.
Instead we have to create a channel to the processes that allows incoming and outgoing communication
in this case what we know about the receiver is the channel it uses to receive data.
In this diagram we can see that the processes are anonymous but we have a channel with I.D. one that
is Channel 1 which connects them together.
This abstraction does not tell us how many processes are in each side of the channel.
It simply connects them and allows communication between processes by using the channel.
The key here is that the channels isolate both extremes so that process they can send data through a
channel that will be handled by potentially one or more processes that are transparent to it.
It also works the same in reverse process B can receive data from many channels one at a time.
Great.
In this video we've explored some basic concepts about go concurrency in the next video we'll learn
to work with go routines.