Hello, guys, welcome back.
And this lecture, we're going to talk about Kyuss.
Now, cues are actually a data structure that we can see it in any course about data structure, about
data science, I mean, Q is a very famous data structure and the way we use it here in a free autos
is in order to share data between two tasks.
So far we did not share any data between desks at desk was doing its job, it was finishing it.
A second task was coming, doing the same thing, or maybe two tasks were doing their job simultaneously.
But we did not actually send data between tasks.
And this is where a cue comes from.
And I'm sure that you heard the term cue before a cue is or what we call first in, first out or FIFO
is actually a data structure that you put data in.
And the first data you put here is the first one that will be out.
It's like the line in a shopping store.
So let's say this is the beginning of the queue.
Customers will come here, then here, then here.
The new one here.
And this is the cashier.
The first one who came will be the first one who is served.
So this is where the queue terminology came from.
So first customer or first is the first one will be out because it's the first one who was served.
Now we're going to use this concept in order to share data between us.
So let's say that we have two tasks.
One of them is sending and the other one is actually receiving.
You might be asking why would I need a queue to do that?
Why don't I just have one variable?
Why do I need all of these?
Why not one variable I sent to it and this one just receives it?
Well, tasks don't perform at the same speed.
So I'm going to give you a very famous example.
Let's say you are trying to process multiple images.
Could be a video.
And let's say that your computer is sending five images per second to your original.
This is hypothetical.
OK, so let's say it's sending five images, but your adrenal is able to process only one image per
second.
The computer is sending five images per second, but your original process, only one in every second.
In this case, your computer is way too fast and this receiver device cannot really keep up in order
to make it keep up.
You would use a buffer like this.
We could call it a buffer here.
This is actually a buffer.
So the first images will be stored here.
Let's say that this buffer can fit 10 images.
So the first one here is being sent.
This one has received it, but there is another four coming.
So they will be stored here.
And once this receiver device is finished processing, it will take the second one and the sender will
be always transmitting and finishing its job early.
So the sender device won't be waiting too long in order to send this to the receiver device.
It's it's the speed is not really conditional with the receiver device.
I mean, this one can keep sending images and the receiver device can to process it on its own pace.
So by that we don't have to make our sender slower in order to make the receiver keep up.
OK, this happens a lot actually.
Inside any hardware, there is always a module that is processing too fast and there is always a module.
But the processing at the lower speed, this happens as well.
Let's say when you are watching YouTube, sometimes what happens is YouTube offers all of those frames
of the video.
Right.
You would see that the slide of the video is going ahead of what you are watching.
Right.
It is already buffering stuff that you did not see yet, so that the speed is always consistent.
Right.
So that you can watch your video without interruption.
So this is actually a buffer.
When you request a video from YouTube, it tries to sense it all with you as fast as possible.
Regardless of how fast you are watching it, though, cuz have a lot of applications and here in between
two tasks, we are going to use Qs for this purpose in order to see if we have two different speeds
so that always the sender can keep sending without having to slow down for the receiver.
OK, I'm going to show you an example.
There is always a point there that says where you are in the queue, so let's say we go to the queue
data, what we have written this, OK, let's say receiver is not receiving anything yet.
We are just sending the receiver was not activated yet, so we provide the first data.
Now, this pointer will move here to tell us that, OK, now we are here.
You can fill data here.
So we are filling data here.
After we fill the data here, this pointer will move here to the third placeholder and it will fill
the data.
So we keep writing to the queue and this pointer keeps moving right until it reaches here.
And it tells us, OK, now the buffer of the queue is full and we cannot write any more.
OK, so this writing device will have to go to the block state and wait for the buffer or the queue
to be emptied in order to be able to write another data.
So this pointer here is very important in order to keep track, where should we put the next data and
is this buffer empty or is it really full?
OK, now let's say that the center desk has stopped and it's not sending anything anymore.
We are doing this so that we can simplify and see how the process works.
Now, let's say the receiver device is actually starting to read from the cue.
The first data that will be read is not actually data file.
Now remember, the last thing we wrote was Data five.
So this will be the last thing to be read.
So now we're going to read data on.
And we will see the pointer moves here, data, too, is being read now, data three, data four, data
five, and now we can not read anything anymore because the pointer is at the head of the queue.
We call the head and it's empty now in the previous case.
Here we were at the tail end of the Q and when we are at the tail, we cannot write anything right because
there is no place to fit it.
Temping here, when we keep reading, we will reach the head and the head.
There is nothing.
Now, usually what happens is thenDo will be writing data.
If the receiver is able to keep up the speed, it will be receiving the data.
So you'll see the queue always like that.
It's filling up a little bit and emptying, filling up a little bit and emptying.
Let's see, the receiver got a little bit busy with something else.
You'll see the buffer just like that.
Maybe the sender is busy with something else and the receiver is really active duty.
See that the buffer is almost empty all the time.
So the buffer here is always varying like that in the data.
OK, so we noticed something as well that when we are reading, we are removing it from the queue.
It's not like we are reading a copy of it.
We are not reading a copy of that.
What we are doing is we are reading the whole thing.
We are reading the whole thing in the queue.
Now this data here is actually a copy of what we have in the central desk.
So let's say the central desk has a value.
It does not really just take the value itself and put it into, you know, it just sends a copy of it
to the queue.
OK, but when reading, we are reading the actual data so that we can free up the Q OK, so by sending
we copy the data we are trying to send to the queue by reading, we are actually taking the data and
removing it from the queue.
Though there are multiple rules, let us recap them.
We cannot write to a full queue because there is no place to write.
We cannot read from an empty queue.
It should generate an error that, OK, the queue is empty.
We cannot really read and the read actually is going to remove that data from the queue.
OK, now the upcoming lectures, we are going to implement this with some real examples.