WEBVTT 00:00.480 --> 00:01.040 Hello. 00:01.140 --> 00:03.060 Welcome to the first section of this course. 00:03.060 --> 00:09.440 Introduction to go concurrency in this section we're going to see concurrency in the Go language. 00:09.440 --> 00:12.830 We'll learn that with multiple cores and multiple processes. 00:12.920 --> 00:17.420 Applications can help us to achieve better performance and endless possibilities. 00:17.450 --> 00:21.680 We'll look at how to use some of the already known patterns in concurrency safe ways. 00:21.680 --> 00:25.830 Now we move onto the first video of this section that deals with defining concurrency. 00:26.060 --> 00:31.880 In this video we'll first get ourselves introduced to the basic concept of concurrency and then understand 00:31.880 --> 00:38.110 the difference between concurrency and parallelism were also tried to compare communicating sequential 00:38.110 --> 00:46.160 processes that is CSP and Acthar based concurrency the creators of the go language wanted garbage collected 00:46.190 --> 00:51.080 and procedural language it is familiar for newcomers but which at the same time can be used to write 00:51.080 --> 00:55.340 concurrent applications easily and without affecting the core of the language. 00:55.340 --> 00:59.300 The concurrent features of the go language are completely separated from the core language while being 00:59.300 --> 01:00.270 part of it. 01:00.320 --> 01:06.410 A perfect example of abstraction and encapsulation there are many concurrency models in computer science. 01:06.410 --> 01:12.530 The most famous being the actor model present in languages such as Erlang or Scala go on the other side 01:12.710 --> 01:18.590 uses communicating sequential processes or CSP which is a different approach to concurrency. 01:18.620 --> 01:24.230 Many people have misunderstood the differences between concurrency and parallelism even thinking they 01:24.230 --> 01:25.340 are the same. 01:25.340 --> 01:31.400 There is a popular speech by Rob Pyke one of the crates of Go concurrency is not parallelism which I 01:31.400 --> 01:33.170 really agree with. 01:33.170 --> 01:38.510 As a quick summary of the talk we can extract these two points which say that concurrency is about dealing 01:38.510 --> 01:43.670 with many things at once and parallelism is about doing many things at the same time. 01:43.670 --> 01:50.310 Concurrency enables parallelism by designing a correct structure of concurrency work. 01:50.430 --> 01:55.100 For example we can think of the mechanism of a bike when we pedal. 01:55.100 --> 02:00.140 We usually push down the pedal to reduce force and this push raises our opposite leg to the opposite 02:00.140 --> 02:01.230 pedal. 02:01.280 --> 02:05.800 We cannot push with both legs at the same time because the cranks don't allow us to do it. 02:05.930 --> 02:11.780 But this design allows the construction of a parallel bike commonly called a tandem bike a tandem bike 02:11.810 --> 02:14.440 is a bike that two people can ride at the same time. 02:14.510 --> 02:21.440 They both pedal and apply force to the bike in the bike example concurrency is the design of a bike 02:21.440 --> 02:26.800 that with two legs that is go routines you can produce power to move the bike by itself. 02:26.930 --> 02:29.990 The design is concurrent and correct. 02:29.990 --> 02:32.120 If we use a tandem bike and two people. 02:32.120 --> 02:36.320 That is to cause the solution is concurrent correct and parallel. 02:36.740 --> 02:41.480 But the key thing is with a concurrent design we don't have to worry about parallelism because we can 02:41.480 --> 02:42.880 think about it as an extra feature. 02:42.890 --> 02:48.440 If our concurrent design is correct in fact we can use the tandem bike with any one person but the concurrent 02:48.440 --> 02:55.750 design of the legs pedals chain wheels the bike is still correct so to recap it is very important to 02:55.750 --> 03:01.660 keep in mind that concurrency is about structure and parallelism is about execution. 03:01.660 --> 03:06.610 We must think about making our programs concurrent in a better way by breaking them down into smaller 03:06.610 --> 03:11.530 pieces of work and goes -- you know we'll tried to make them parallel if it's possible and allowed 03:13.940 --> 03:17.070 now before we move on to some practical tasks and code. 03:17.180 --> 03:19.720 There is another important concept we have to understand. 03:20.060 --> 03:26.000 We need to have a clear understanding about communicating sequential processes or CSP vs. act based 03:26.060 --> 03:31.930 concurrency the most common and perhaps intuitive way to think about concurrency is close to the way 03:31.930 --> 03:34.980 the actor model works in the actor model. 03:34.990 --> 03:40.570 In fact no one wants to communicate with actor to an actor one must know actor to first for example. 03:40.570 --> 03:45.560 It must have its process I.D. may maybe from the creation step and put a message on its inbox. 03:45.570 --> 03:50.530 Q After placing the message Actor 1 can continue its tasks without getting blocked. 03:50.530 --> 03:57.220 If ACTOR 2 cannot process the message immediately CSP on the other side introduces a new entity into 03:57.220 --> 04:02.830 the equation channels channels are a way to communicate between processes because they are completely 04:02.830 --> 04:04.030 anonymous. 04:04.030 --> 04:08.170 In the case of CSP we don't have a process I.D. to use to communicate. 04:08.170 --> 04:12.880 Instead we have to create a channel to the processes that allows incoming and outgoing communication 04:14.600 --> 04:19.340 in this case what we know about the receiver is the channel it uses to receive data. 04:19.340 --> 04:24.440 In this diagram we can see that the processes are anonymous but we have a channel with I.D. one that 04:24.440 --> 04:28.180 is Channel 1 which connects them together. 04:28.200 --> 04:31.950 This abstraction does not tell us how many processes are in each side of the channel. 04:31.950 --> 04:36.700 It simply connects them and allows communication between processes by using the channel. 04:36.720 --> 04:41.910 The key here is that the channels isolate both extremes so that process they can send data through a 04:41.910 --> 04:46.570 channel that will be handled by potentially one or more processes that are transparent to it. 04:46.920 --> 04:52.170 It also works the same in reverse process B can receive data from many channels one at a time. 04:52.170 --> 04:52.870 Great. 04:53.190 --> 04:58.890 In this video we've explored some basic concepts about go concurrency in the next video we'll learn 04:58.890 --> 05:00.210 to work with go routines.