1
00:00:00,000 --> 00:00:06,200
[No Audio]

2
00:00:06,201 --> 00:00:08,189
In this tutorial we will be looking at three

3
00:00:08,190 --> 00:00:10,319
concepts related to message passing. So let's

4
00:00:10,320 --> 00:00:13,049
start. We will first learn how to send out

5
00:00:13,050 --> 00:00:15,449
multiple messages, I will start by bringing

6
00:00:15,450 --> 00:00:17,266
the relevant modules into scope.

7
00:00:17,267 --> 00:00:21,808
[No Audio]

8
00:00:21,809 --> 00:00:23,566
Let me first create a channel.

9
00:00:23,567 --> 00:00:28,860
[No Audio]

10
00:00:28,861 --> 00:00:31,350
Next I will create a thread and we'll assign

11
00:00:31,351 --> 00:00:32,714
it to a variable.

12
00:00:32,715 --> 00:00:38,610
[No Audio]

13
00:00:38,611 --> 00:00:40,770
Inside the thread, I will create a vector and

14
00:00:40,771 --> 00:00:42,810
then I will send the values in the vector one

15
00:00:42,811 --> 00:00:45,366
by one to the receiver. So let me create a vector first.

16
00:00:45,367 --> 00:00:51,090
[No Audio]

17
00:00:51,091 --> 00:00:53,600
Next I will iterate through the values one by one.

18
00:00:53,601 --> 00:00:57,266
[No Audio]

19
00:00:57,267 --> 00:00:59,100
During each iteration, I will send out

20
00:00:59,101 --> 00:01:00,660
one of the values.

21
00:01:00,661 --> 00:01:07,980
[No Audio]

22
00:01:07,981 --> 00:01:10,260
Now inside the main thread, I can use the

23
00:01:10,261 --> 00:01:13,230
variable rx to receive the values. I will use

24
00:01:13,231 --> 00:01:15,700
a for loop for this purpose on the variable of rx.

25
00:01:15,701 --> 00:01:22,950
[No Audio]

26
00:01:22,951 --> 00:01:25,350
This syntax means that I will iterate as many

27
00:01:25,351 --> 00:01:28,866
times as there are available values in the rx.

28
00:01:29,100 --> 00:01:31,410
Next inside the loop I will print out the

29
00:01:31,440 --> 00:01:33,133
received values.

30
00:01:33,134 --> 00:01:39,180
[No Audio]

31
00:01:39,181 --> 00:01:40,950
You may note that in the main thread, we are

32
00:01:40,951 --> 00:01:43,230
not calling the receive function explicitly

33
00:01:43,231 --> 00:01:46,410
anymore. Instead we are treating rx as an

34
00:01:46,440 --> 00:01:49,170
iterator for each value received we are

35
00:01:49,171 --> 00:01:51,420
printing it, when the channel is closed

36
00:01:51,450 --> 00:01:54,100
iteration will end let us cargo run this now.

37
00:01:54,101 --> 00:01:59,250
[No Audio]

38
00:01:59,251 --> 00:02:01,980
We may also use the iter function instead of

39
00:02:01,981 --> 00:02:04,980
the for loop, let us use it. I will first

40
00:02:04,981 --> 00:02:06,400
call the iter function.

41
00:02:06,401 --> 00:02:09,078
[No Audio]

42
00:02:09,079 --> 00:02:10,229
Next I will collect

43
00:02:10,230 --> 00:02:12,630
all the values in the in a suitable container

44
00:02:12,840 --> 00:02:15,360
which will be i32 vector in this case.

45
00:02:15,361 --> 00:02:20,670
[No Audio]

46
00:02:20,671 --> 00:02:22,533
Finally, I will print all the values.

47
00:02:22,534 --> 00:02:27,386
[No Audio]

48
00:02:27,387 --> 00:02:28,833
Let us cargo run this now.

49
00:02:28,834 --> 00:02:33,985
[No Audio]

50
00:02:33,986 --> 00:02:36,750
Let us now learn how we can define multiple

51
00:02:36,751 --> 00:02:39,300
producers or senders of the data, that works

52
00:02:39,301 --> 00:02:41,220
with a single consumer or receiver of the

53
00:02:41,221 --> 00:02:43,860
data. I will comment out all the code and

54
00:02:43,861 --> 00:02:45,200
we'll start fresh again.

55
00:02:45,201 --> 00:02:50,190
[No Audio]

56
00:02:50,191 --> 00:02:52,800
First I will bring the relevant modules into scope.

57
00:02:52,801 --> 00:02:58,920
[No Audio]

58
00:02:58,921 --> 00:03:01,200
The time duration module will be used to halt

59
00:03:01,201 --> 00:03:04,110
the execution of a thread for some time, I

60
00:03:04,111 --> 00:03:05,430
will first define a channel.

61
00:03:05,431 --> 00:03:10,770
[No Audio]

62
00:03:10,771 --> 00:03:12,900
I will assume that there are two centers of

63
00:03:12,901 --> 00:03:16,133
the data in this case next, I will spawn a thread.

64
00:03:16,134 --> 00:03:21,960
[No Audio]

65
00:03:21,961 --> 00:03:23,700
Inside the thread I will create a vector

66
00:03:23,701 --> 00:03:25,350
first containing some values.

67
00:03:25,351 --> 00:03:30,690
[No Audio]

68
00:03:30,691 --> 00:03:32,670
Next, I will send out all the values in a

69
00:03:32,671 --> 00:03:35,066
vector one by one so I will include a for loop.

70
00:03:35,067 --> 00:03:39,600
[No Audio]

71
00:03:39,601 --> 00:03:41,550
During each iteration, I will send out

72
00:03:41,551 --> 00:03:43,043
one of the values.

73
00:03:43,044 --> 00:03:50,400
[No Audio]

74
00:03:50,401 --> 00:03:52,680
After sending out the value I want to give

75
00:03:52,681 --> 00:03:55,380
more chance to another sending threads, so

76
00:03:55,381 --> 00:03:57,570
therefore I will halt the execution of this

77
00:03:57,571 --> 00:04:00,466
thread for a little time by calling the sleep function.

78
00:04:00,467 --> 00:04:06,120
[No Audio]

79
00:04:06,121 --> 00:04:08,850
This thread code is now complete all this

80
00:04:08,851 --> 00:04:11,070
thread is doing is that it will send out the

81
00:04:11,071 --> 00:04:13,560
values inside the vector one by one and after

82
00:04:13,561 --> 00:04:15,870
sending each value it will halt the execution

83
00:04:15,871 --> 00:04:18,029
of itself for some time before sending out

84
00:04:18,030 --> 00:04:21,089
the next value. The second thread will have

85
00:04:21,090 --> 00:04:23,233
very similar code to the first trend.

86
00:04:23,241 --> 00:04:25,633
So I will copy the code of the trend and we'll paste it.

87
00:04:25,634 --> 00:04:32,430
[No Audio]

88
00:04:32,431 --> 00:04:34,900
I will just change the values inside the vector.

89
00:04:34,901 --> 00:04:40,740
[No Audio]

90
00:04:40,741 --> 00:04:43,080
You may note an error in this case. This is

91
00:04:43,081 --> 00:04:45,870
because the tx variable has been moved, inside

92
00:04:45,871 --> 00:04:48,400
the first thread and is therefore no more available.

93
00:04:48,633 --> 00:04:50,460
To get around this, we will make a

94
00:04:50,461 --> 00:04:53,070
clone copy of tx and we'll use this handle to

95
00:04:53,071 --> 00:04:55,740
send out messages in the second spawn thread.

96
00:04:55,741 --> 00:05:02,220
[No Audio]

97
00:05:02,221 --> 00:05:04,320
This will enable the second producer of the

98
00:05:04,321 --> 00:05:07,350
data to send out data. In general to send out

99
00:05:07,351 --> 00:05:09,510
the data using the same channel we will need

100
00:05:09,511 --> 00:05:11,850
to make a clone copy of the sender variable

101
00:05:13,080 --> 00:05:14,910
in the main now I will add code for

102
00:05:14,911 --> 00:05:17,130
receiving the values, I will iterate through

103
00:05:17,131 --> 00:05:19,080
all the values that are being received using

104
00:05:19,081 --> 00:05:20,729
the variable of rx.

105
00:05:20,730 --> 00:05:26,970
[No Audio]

106
00:05:26,971 --> 00:05:29,520
Next, I will print out the received values.

107
00:05:29,521 --> 00:05:34,740
[No Audio]

108
00:05:34,764 --> 00:05:36,204
Let us cargo run this now.

109
00:05:36,205 --> 00:05:42,570
[No Audio]

110
00:05:42,571 --> 00:05:45,060
You may note that, after each received value

111
00:05:45,061 --> 00:05:48,030
there is some pause or wait and this is,

112
00:05:48,031 --> 00:05:49,980
because the main thread has to wait for the

113
00:05:49,981 --> 00:05:52,320
next value to be received. This is due to the

114
00:05:52,321 --> 00:05:54,180
sleep function which causes the thread to

115
00:05:54,181 --> 00:05:56,730
pause for some time before sending out an x

116
00:05:56,731 --> 00:05:59,190
value. Moreover, the values are received from

117
00:05:59,191 --> 00:06:01,666
the two threads in an arbitrary order.

118
00:06:02,533 --> 00:06:04,740
The final point to note is that the values that

119
00:06:04,741 --> 00:06:06,780
are sent out from a specific thread are

120
00:06:06,781 --> 00:06:09,480
always received in the correct order. This

121
00:06:09,481 --> 00:06:11,670
means that the values from the first thread

122
00:06:11,700 --> 00:06:13,950
which are the values from 1 to 5 are

123
00:06:13,951 --> 00:06:16,133
always going to be received in the same order.

124
00:06:16,333 --> 00:06:18,570
That is the value one is always going

125
00:06:18,571 --> 00:06:20,850
to be the first value received from the first

126
00:06:20,851 --> 00:06:23,010
thread, and therefore is going to be displayed

127
00:06:23,011 --> 00:06:25,650
first followed by the value of 2 and so on.

128
00:06:26,160 --> 00:06:28,530
The value 2 can never be received before

129
00:06:28,531 --> 00:06:31,080
the value 1. This is due to the fee for

130
00:06:31,081 --> 00:06:33,990
nature of the queue. That is first in first

131
00:06:33,991 --> 00:06:36,270
out, since the value one is the first one

132
00:06:36,271 --> 00:06:38,370
which has been sent out by the thread 1

133
00:06:38,430 --> 00:06:40,800
therefore it is always going to be received

134
00:06:40,801 --> 00:06:43,980
first. The same is also true for the second

135
00:06:43,981 --> 00:06:46,140
thread, the value 6 will always be the

136
00:06:46,141 --> 00:06:48,630
first value received from the second thread

137
00:06:48,631 --> 00:06:51,300
followed by the value 7 and so on. In

138
00:06:51,301 --> 00:06:53,520
summary within the thread the execution is

139
00:06:53,550 --> 00:06:55,920
always sequential and therefore the output is

140
00:06:55,921 --> 00:06:58,620
always deterministic however, between the

141
00:06:58,621 --> 00:07:00,720
threads the execution is not sequential and

142
00:07:00,721 --> 00:07:02,310
therefore the output may be and

143
00:07:02,311 --> 00:07:05,880
deterministic. Let us now move to the final

144
00:07:05,881 --> 00:07:08,070
topic. I will comment out the code and we'll

145
00:07:08,071 --> 00:07:09,263
start fresh again.

146
00:07:09,271 --> 00:07:17,300
[No Audio]

147
00:07:17,301 --> 00:07:19,900
Let us first bring the relevant modules in the scope.

148
00:07:19,901 --> 00:07:25,680
[No Audio]

149
00:07:25,681 --> 00:07:27,630
The final topic is related to the use of

150
00:07:27,631 --> 00:07:30,240
threads inside functions, let us define a

151
00:07:30,241 --> 00:07:32,430
function that will accept an i32 value

152
00:07:32,431 --> 00:07:33,840
and a variable of type center.

153
00:07:33,866 --> 00:07:42,660
[No Audio]

154
00:07:42,661 --> 00:07:44,910
The sender will send out i32 values

155
00:07:44,911 --> 00:07:47,310
therefore, we mentioned that inside the

156
00:07:47,311 --> 00:07:49,050
function we will first create a thread.

157
00:07:49,051 --> 00:07:54,090
[No Audio]

158
00:07:54,091 --> 00:07:56,549
Inside the thread, we will print out the variable d.

159
00:07:56,550 --> 00:08:01,566
[No Audio]

160
00:08:01,567 --> 00:08:02,880
Next, we will send out the

161
00:08:02,881 --> 00:08:04,590
variable d to the calling function.

162
00:08:04,591 --> 00:08:11,100
[No Audio]

163
00:08:11,101 --> 00:08:13,260
In the main function now, we will first

164
00:08:13,261 --> 00:08:14,866
declare a channel.

165
00:08:14,867 --> 00:08:19,273
[No Audio]

166
00:08:19,274 --> 00:08:20,580
Next we would like to call

167
00:08:20,581 --> 00:08:22,890
the function 5 times. So I will create a

168
00:08:22,891 --> 00:08:24,333
for loop for this purpose.

169
00:08:24,334 --> 00:08:28,900
[No Audio]

170
00:08:28,901 --> 00:08:31,200
During each iteration, I will call the function with the

171
00:08:31,201 --> 00:08:34,559
variable i and a clone copy of the sender.

172
00:08:34,560 --> 00:08:41,519
[No Audio]

173
00:08:41,520 --> 00:08:43,558
Next I will create a for loop for receiving

174
00:08:43,589 --> 00:08:45,066
all the values.

175
00:08:45,067 --> 00:08:50,549
[No Audio]

176
00:08:50,550 --> 00:08:52,439
Inside the for loop I will add a print

177
00:08:52,440 --> 00:08:54,701
statement for displaying the received values.

178
00:08:54,702 --> 00:09:01,049
[No Audio]

179
00:09:01,050 --> 00:09:02,819
Let us cargo run this and you may note

180
00:09:02,820 --> 00:09:04,233
something interesting.

181
00:09:04,234 --> 00:09:09,149
[No Audio]

182
00:09:09,150 --> 00:09:11,279
The execution is not stopping which means

183
00:09:11,280 --> 00:09:13,289
that the code is still in process. Let me

184
00:09:13,290 --> 00:09:16,169
forcefully stop it by pressing Ctrl + C.

185
00:09:17,429 --> 00:09:19,799
Let us explain why this happened. During each

186
00:09:19,800 --> 00:09:21,749
execution of the function we are passing a

187
00:09:21,750 --> 00:09:23,819
clone of the sender to the function the

188
00:09:23,820 --> 00:09:26,429
function is using the actual values and

189
00:09:26,459 --> 00:09:28,919
assume the ownership of the clone of the

190
00:09:28,920 --> 00:09:31,379
sender. When the function is over the sender

191
00:09:31,380 --> 00:09:33,389
is dropped and therefore the clone of sender

192
00:09:33,390 --> 00:09:35,849
is no more in scope. However, the original

193
00:09:35,850 --> 00:09:37,979
sender is still alive in the main thread as

194
00:09:37,980 --> 00:09:40,229
we always send out the clone of the sender

195
00:09:40,230 --> 00:09:42,929
and not the original sender. The important

196
00:09:42,930 --> 00:09:44,999
point to note is that if the sender is alive

197
00:09:45,000 --> 00:09:47,369
and in scope, then the receiver will keep on

198
00:09:47,370 --> 00:09:49,349
waiting since it is believing that one of the

199
00:09:49,350 --> 00:09:51,569
sender is still alive and he may send out a

200
00:09:51,570 --> 00:09:54,479
message. As a result the program goes to a

201
00:09:54,480 --> 00:09:57,029
waiting state. In summary if any of the

202
00:09:57,030 --> 00:09:59,699
sender is alive for a specific channel, then

203
00:09:59,731 --> 00:10:01,351
the receiver will keep on waiting for

204
00:10:01,352 --> 00:10:03,959
the values in the same channel, in the hope

205
00:10:03,960 --> 00:10:06,433
that someone may send out a message.

206
00:10:06,566 --> 00:10:09,779
To make sure that this program gets executed

207
00:10:09,780 --> 00:10:12,779
correctly, we will make sure that the sender

208
00:10:12,780 --> 00:10:15,299
tx is dropped before we start to receive the

209
00:10:15,300 --> 00:10:19,049
values using the for loop. This code will now

210
00:10:19,050 --> 00:10:21,329
go to completion since all the senators are

211
00:10:21,330 --> 00:10:24,809
done with their job. The last point to note

212
00:10:24,810 --> 00:10:28,233
is that it is not necessity that the value 0

213
00:10:28,234 --> 00:10:30,389
will always be sent out first followed

214
00:10:30,390 --> 00:10:33,269
by the value 1 and so on. Let me execute a

215
00:10:33,270 --> 00:10:35,189
few more times and you may notice.

216
00:10:35,190 --> 00:10:40,889
[No Audio]

217
00:10:40,890 --> 00:10:43,739
The code inside the thread although runs in

218
00:10:43,740 --> 00:10:46,499
sequential order, however, during each call

219
00:10:46,529 --> 00:10:48,209
inside the function we are creating the

220
00:10:48,210 --> 00:10:50,069
threads so therefore the values may be sent

221
00:10:50,070 --> 00:10:52,709
out in different order. Finally, the value

222
00:10:52,710 --> 00:10:54,929
which is sent out first is always going to be

223
00:10:54,930 --> 00:10:57,479
the values which is received first. This is

224
00:10:57,480 --> 00:10:59,459
again related to the fact that the channels

225
00:10:59,460 --> 00:11:02,399
implemented for order that is first in first

226
00:11:02,400 --> 00:11:05,459
out that is it for this particular tutorial.

227
00:11:05,489 --> 00:11:07,289
I hope you would have enjoyed this see you

228
00:11:07,290 --> 00:11:09,300
again and ultimately next tutorial.

229
00:11:09,366 --> 00:11:10,900
Happy Rust programming.

230
00:11:10,901 --> 00:11:15,100
[No Audio]