1
00:00:06,000 --> 00:00:06,000
Hello.

2
00:00:06,000 --> 00:00:12,000
There are students in this lesson, we'll learn implementations of executive service interface and parents

3
00:00:12,000 --> 00:00:12,000
lessons.

4
00:00:12,000 --> 00:00:19,000
We learned what executive interface is and what executive service interface is to show them.

5
00:00:19,000 --> 00:00:25,000
I had to use one implementation of executive service that today will require different implementations

6
00:00:25,000 --> 00:00:31,000
of this interface and different use cases so that you'll know when to use one specific implementation.

7
00:00:32,000 --> 00:00:38,000
Today will review fix reticule executer cash, streetball, single streetball, shadowless reticule.

8
00:00:39,000 --> 00:00:41,000
As we will go over each executer one by one.

9
00:00:41,000 --> 00:00:48,000
I will also explain what threat factor is and how you can use it during the installation of threats.

10
00:00:48,000 --> 00:00:54,000
You understand what a threat starvation is and how to calculate a perfect number of threats for your

11
00:00:54,000 --> 00:00:55,000
threat pool.

12
00:00:55,000 --> 00:01:00,000
I'm going to show you formulas and we'll teach you how to calculate the blocking coefficient.

13
00:01:01,000 --> 00:01:04,000
And as always, we are going to have a lot of examples to the source.

14
00:01:04,000 --> 00:01:08,000
Code of all examples is in attachment to this lesson.

15
00:01:08,000 --> 00:01:10,000
Let's start today.

16
00:01:10,000 --> 00:01:14,000
We'll learn with you everything from official documentation and the code examples.

17
00:01:14,000 --> 00:01:16,000
So let me start screen sharing.

18
00:01:17,000 --> 00:01:19,000
I open source code of executor's class.

19
00:01:20,000 --> 00:01:25,000
I believe you remember that we have factory mascots in this class that allows us to create instances

20
00:01:25,000 --> 00:01:31,000
of different implementations of executive service interface and considerable amount of this factory

21
00:01:31,000 --> 00:01:33,000
masses and level of details.

22
00:01:33,000 --> 00:01:39,000
I would like to focus your attention on the difference between all of them and the main features rather

23
00:01:39,000 --> 00:01:41,000
than on the source code of each particular executer.

24
00:01:42,000 --> 00:01:43,000
So let's go one by one.

25
00:01:44,000 --> 00:01:47,000
We will start from the top from the first factory mass.

26
00:01:48,000 --> 00:01:53,000
This method is called new fixed thread pool and takes in value as method argument.

27
00:01:54,000 --> 00:01:57,000
You can see that we reach an object of streetball executive type.

28
00:01:58,000 --> 00:01:59,000
Let me open this one.

29
00:01:59,000 --> 00:02:07,000
SWEPCO executive type extends Abstract Executive Service Zissis abstract class that is used by different

30
00:02:07,000 --> 00:02:14,000
implementations of executive service, the common implementations of some methods that are appropriate

31
00:02:14,000 --> 00:02:18,000
for all concrete classes that extends this abasic one.

32
00:02:18,000 --> 00:02:25,000
And as you can see, abstract executive service implements executive service, which in turn implements

33
00:02:25,000 --> 00:02:29,000
executer hope that the Iraqi is clear for you.

34
00:02:29,000 --> 00:02:33,000
It will be similar for other executor's for our lesson today.

35
00:02:34,000 --> 00:02:36,000
Let's now get back to Executor's.

36
00:02:36,000 --> 00:02:44,000
So this massive new streetball grades and executive service that we use as fixed number of threats,

37
00:02:44,000 --> 00:02:48,000
the fixed number of threats is passed to the method as methods argument.

38
00:02:49,000 --> 00:02:50,000
The idea is simple.

39
00:02:50,000 --> 00:02:56,000
All threats work on tasks in parallel, depending on your computer characteristics.

40
00:02:56,000 --> 00:03:03,000
The number of threads running simultaneously and in parallel is different in case the more tasks than

41
00:03:03,000 --> 00:03:10,000
current threats available to execute those tasks will wait in the queue until any threat from the pool

42
00:03:10,000 --> 00:03:11,000
will be available again.

43
00:03:11,000 --> 00:03:17,000
What will happen in case any other threats will be terminated because of the failure during the execution,

44
00:03:18,000 --> 00:03:22,000
new one will be created and take its place to execute subsequent tasks.

45
00:03:22,000 --> 00:03:24,000
Let's look at the example now.

46
00:03:24,000 --> 00:03:30,000
I open the fixed thread, pull them across all executer examples that I will show you today.

47
00:03:30,000 --> 00:03:38,000
Located in executor's package, you can find a link to the package was all executor's examples in attachments

48
00:03:38,000 --> 00:03:39,000
to this lesson.

49
00:03:39,000 --> 00:03:44,000
I create my Reppel executer, pay attention and create a pool for three threats.

50
00:03:45,000 --> 00:03:51,000
Also, you can see that I cost object here because factoring in massive new fixed rate pool declares

51
00:03:51,000 --> 00:03:58,000
that executive service will be returned and recommends us to operate with objects on this abstraction

52
00:03:58,000 --> 00:03:58,000
level.

53
00:03:59,000 --> 00:04:03,000
But we know that this concrete implementation of executive service will be used.

54
00:04:04,000 --> 00:04:09,000
I need this to show your class specific matters that are absent in executive service.

55
00:04:09,000 --> 00:04:13,000
After that, I submit for similar tasks to the executive service.

56
00:04:14,000 --> 00:04:17,000
Each task sleep for one second and that's it.

57
00:04:18,000 --> 00:04:24,000
I need the sleep for the sake of example, I call shut down MassArt here to not allow anyone to submit

58
00:04:24,000 --> 00:04:28,000
any other tasks to this executive service after this line.

59
00:04:29,000 --> 00:04:32,000
After that I principle size and Q's size.

60
00:04:32,000 --> 00:04:39,000
These are class specific masses that are absent in executive service, but that will allow us to show

61
00:04:39,000 --> 00:04:41,000
the future of fixed threat pool.

62
00:04:41,000 --> 00:04:42,000
Let me run the program.

63
00:04:43,000 --> 00:04:47,000
I run the program and I can see that pool size is three.

64
00:04:47,000 --> 00:04:50,000
The number of threats that I have in my pool.

65
00:04:50,000 --> 00:04:56,000
I passed this number to the factory Masset and number of tasks in queue is one.

66
00:04:56,000 --> 00:05:02,000
That is because each task sleeps one second and the fourth task has no threats that would.

67
00:05:03,000 --> 00:05:09,000
I said that's why it is in queue for the execution, but once these tasks are finished, one of the

68
00:05:09,000 --> 00:05:11,000
threats is the last one.

69
00:05:12,000 --> 00:05:15,000
Once all tasks are processed, UVM is finished.

70
00:05:16,000 --> 00:05:20,000
That is because I call shut down MassArt, imperfect world.

71
00:05:20,000 --> 00:05:26,000
I should call every termination Hendel potential interrupted exception and call shut down now.

72
00:05:26,000 --> 00:05:32,000
But we discussed this in previous lesson and to not write a lot of code that doesn't directly relate

73
00:05:32,000 --> 00:05:34,000
to the topic today, I will skip it.

74
00:05:34,000 --> 00:05:40,000
But please make sure you learned well previous lesson and you know how to terminate multiple threats.

75
00:05:40,000 --> 00:05:46,000
With the help of executive service, my students often ask me how to define ideal number of threats

76
00:05:46,000 --> 00:05:48,000
to create infix threat pool.

77
00:05:49,000 --> 00:05:54,000
I mean, what criteria we should use to define whether we need to create four, eight or chanceries

78
00:05:54,000 --> 00:05:55,000
in pool.

79
00:05:56,000 --> 00:06:02,000
It is not an easy question, but I will try explain it as simple as possible before calculating perfect

80
00:06:02,000 --> 00:06:03,000
number of threats.

81
00:06:03,000 --> 00:06:05,000
You should understand your limits.

82
00:06:05,000 --> 00:06:09,000
And I'm talking not only about a number of CPU's in your computer.

83
00:06:10,000 --> 00:06:12,000
I also want to draw attention to other limits.

84
00:06:13,000 --> 00:06:17,000
For example, Zamunda limit on number of connections to a database.

85
00:06:17,000 --> 00:06:23,000
Does it make sense to have one hundred twines threats that interact with database and have limited database

86
00:06:23,000 --> 00:06:25,000
connection with ten connections?

87
00:06:25,000 --> 00:06:27,000
Only the answer is obvious.

88
00:06:28,000 --> 00:06:34,000
Or if a threat interacts with other system and sends a request to the APIs that can produce only a few

89
00:06:34,000 --> 00:06:35,000
requests simultaneously.

90
00:06:36,000 --> 00:06:43,000
This fact also needs to be considered because in the most pessimistic case, we may end up with reservation

91
00:06:43,000 --> 00:06:45,000
state or even without of memory error.

92
00:06:46,000 --> 00:06:47,000
What a threat.

93
00:06:47,000 --> 00:06:47,000
Starvation.

94
00:06:48,000 --> 00:06:54,000
Starvation describes a situation where Sweat is unable to gain regular access to shared resources and

95
00:06:54,000 --> 00:06:56,000
is unable to make progress.

96
00:06:56,000 --> 00:07:02,000
This happens when shared resources are made unavailable for long periods of grief threats.

97
00:07:02,000 --> 00:07:07,000
And of course, another important factor to consider is number of years.

98
00:07:07,000 --> 00:07:13,000
You can identify a number of tips like this call runtime static MassArt on runtime Closs.

99
00:07:14,000 --> 00:07:20,000
You would get the reference to the runtime object and invoke available processers you will get enough

100
00:07:20,000 --> 00:07:21,000
value.

101
00:07:21,000 --> 00:07:24,000
This would be the number, of course, on your computer.

102
00:07:24,000 --> 00:07:31,000
Be careful with this massive one you will work with container's this approach might provide it was wrong

103
00:07:31,000 --> 00:07:34,000
information without any specific constraints.

104
00:07:34,000 --> 00:07:41,000
A continuous process will be able to see the hardware on the operating system and it might happen at

105
00:07:41,000 --> 00:07:43,000
your containerised application.

106
00:07:43,000 --> 00:07:48,000
Supposedly is too coarse only, but your operating system has eight.

107
00:07:48,000 --> 00:07:52,000
So just be careful when you rely on this value.

108
00:07:52,000 --> 00:07:59,000
Here we have another variable executive service, too, and I want to show you that you can initialised

109
00:07:59,000 --> 00:08:04,000
your executive service just like this in one line by passing the number, of course, to the masses.

110
00:08:05,000 --> 00:08:11,000
But still, I mentioned the different factors that would impact our decision and that will help us to

111
00:08:11,000 --> 00:08:13,000
answer what is a growing number of threats.

112
00:08:13,000 --> 00:08:15,000
And it took great in my streetball.

113
00:08:15,000 --> 00:08:19,000
Let's review a formula from book Java Concurrency.

114
00:08:19,000 --> 00:08:25,000
In practice, number of threads equal to the number of available course multiplied by the result of

115
00:08:25,000 --> 00:08:30,000
the next expression one plus the result of division between the wait time and service time.

116
00:08:31,000 --> 00:08:34,000
Don't worry, it is not so scary as it looks like.

117
00:08:34,000 --> 00:08:41,000
And the first glance, let's review it in detail and we need to understand first what is the wait time

118
00:08:41,000 --> 00:08:42,000
and what is a service?

119
00:08:42,000 --> 00:08:49,000
Time wasting time is a time spent waiting for inputs and outputs bound tasks to complete.

120
00:08:49,000 --> 00:08:55,000
For example, this is not the amount of time you're waiting for a response from remote server.

121
00:08:56,000 --> 00:09:03,000
And this is just one example because it might be not only input output tasks, but any tasks that makes

122
00:09:03,000 --> 00:09:09,000
execution wait for some event and as examples might be getting monitor log.

123
00:09:09,000 --> 00:09:10,000
What is service time?

124
00:09:11,000 --> 00:09:13,000
Service time is a useful time.

125
00:09:13,000 --> 00:09:21,000
The time spent being busy, for example, process HTP, response, data filtering or transformation,

126
00:09:21,000 --> 00:09:27,000
etc. So dividing the waiting time by service time will get the result that is often called blocking

127
00:09:27,000 --> 00:09:32,000
coefficient, a computation intensive task Hasbrouck and coefficient close to zero.

128
00:09:33,000 --> 00:09:39,000
Now let's assume that we have four CPUs and let's substitute numbers in the formula with your data and

129
00:09:39,000 --> 00:09:41,000
zero for blocking creation.

130
00:09:42,000 --> 00:09:44,000
What result you have in this case?

131
00:09:44,000 --> 00:09:47,000
The number of threads is equal to the number of available course.

132
00:09:47,000 --> 00:09:52,000
If all tasks are computation intensive, then this is all we need.

133
00:09:52,000 --> 00:09:59,000
And having more threats won't help us to improve performance because we respect the restriction of having

134
00:09:59,000 --> 00:10:01,000
a limited number of CPUs.

135
00:10:02,000 --> 00:10:03,000
Now, let's give you another example.

136
00:10:04,000 --> 00:10:09,000
Imagine that our application process, different amount of data that is read from the server in the

137
00:10:09,000 --> 00:10:12,000
Internet, you just send the request.

138
00:10:12,000 --> 00:10:19,000
And the way the response was, the data program reads a bunch of data and processes it after that program,

139
00:10:19,000 --> 00:10:26,000
reads another batch of data and processes it again, having the performance benchmark evaluation.

140
00:10:26,000 --> 00:10:32,000
You know, that process of reviewing one batch takes two hundred milliseconds, for example, and time

141
00:10:32,000 --> 00:10:33,000
of processing of this data.

142
00:10:34,000 --> 00:10:35,000
Take 20 milliseconds.

143
00:10:36,000 --> 00:10:38,000
Let's substitute numbers in our formula.

144
00:10:39,000 --> 00:10:43,000
And in this case, following calculations in formula, we need forty four sets.

145
00:10:44,000 --> 00:10:46,000
It seems to be a big amount of threats.

146
00:10:46,000 --> 00:10:48,000
Let's think about it from another point of view.

147
00:10:49,000 --> 00:10:55,000
You're going to have tasks that will be blocked waiting for two hundred milliseconds and what these

148
00:10:55,000 --> 00:10:58,000
threats should do, just sitting and waiting.

149
00:10:58,000 --> 00:11:02,000
They're doing exactly this thing, sitting and waiting.

150
00:11:02,000 --> 00:11:08,000
And in the meantime, we have processors that are ready and happy to execute any other computations.

151
00:11:09,000 --> 00:11:14,000
That's why in this particular case, with such weighting and service time, it is reasonable to have

152
00:11:14,000 --> 00:11:17,000
44 phosphorescence a fixed rate pool.

153
00:11:17,000 --> 00:11:22,000
There is a good practice to have separate executive services for each set of tasks.

154
00:11:22,000 --> 00:11:28,000
In this case, each executive service may be configured accordingly for a specific class of tasks,

155
00:11:29,000 --> 00:11:31,000
and one would have multiple executive services.

156
00:11:31,000 --> 00:11:36,000
We need to adjust our formula by adding CPU utilization parameter to it.

157
00:11:37,000 --> 00:11:37,000
What?

158
00:11:37,000 --> 00:11:45,000
Well, you may be in target CPU utilization variable from zero to one inclusively where zero means that

159
00:11:45,000 --> 00:11:52,000
streetball want to use processors at all and one means that streetball will use one hundred percent

160
00:11:52,000 --> 00:11:53,000
of processors for time.

161
00:11:54,000 --> 00:11:56,000
The formula becomes localizes.

162
00:11:57,000 --> 00:12:04,000
In the similar case, and if I plan to grant only 50 percent of processers time to the batch data processing

163
00:12:04,000 --> 00:12:11,000
and another 50 percent will be dedicated to other activities or other executive service, we are going

164
00:12:11,000 --> 00:12:12,000
to have another result.

165
00:12:13,000 --> 00:12:20,000
I add a zero point five to reflect targeted utilization and as a result, we have twenty two threats.

166
00:12:20,000 --> 00:12:26,000
This number of threats you need to create in streetball to be efficient with these group of tasks.

167
00:12:27,000 --> 00:12:33,000
Definitely life cases are different and it is not always so easy to calculate weighting and service

168
00:12:33,000 --> 00:12:35,000
time for each task that you are going to create.

169
00:12:36,000 --> 00:12:42,000
That's why these formulas are just a great starting point for you and hope that these formulas will

170
00:12:42,000 --> 00:12:47,000
help you to understand the motivation to make a final decision regarding a number of threads in the

171
00:12:47,000 --> 00:12:48,000
thread.

172
00:12:49,000 --> 00:12:54,000
OK, now when you know, let's get back to Demo New Fix.

173
00:12:54,000 --> 00:13:01,000
Red Bull Market is overloaded and has versions that accepts in value and threat factor what is a threat

174
00:13:01,000 --> 00:13:01,000
factor.

175
00:13:02,000 --> 00:13:04,000
Let's open the source code of this type.

176
00:13:04,000 --> 00:13:11,000
Objects of a threat factory type are used to create new threats by giving implementation to the new

177
00:13:11,000 --> 00:13:12,000
threat massive.

178
00:13:12,000 --> 00:13:18,000
You can define the process and activities that are needed to be executed during the threat creation.

179
00:13:18,000 --> 00:13:24,000
Let me explain to you with the example I open threat factor factory demo file.

180
00:13:24,000 --> 00:13:29,000
I create a variable that would store WELI of number of threats in a threat posed.

181
00:13:30,000 --> 00:13:34,000
I create executive service and have fixed number of threats input.

182
00:13:35,000 --> 00:13:38,000
And when I create executive service, I call masses.

183
00:13:38,000 --> 00:13:41,000
It also takes threat factor as my argument.

184
00:13:41,000 --> 00:13:44,000
I pass object of the false threat factory type.

185
00:13:45,000 --> 00:13:46,000
What is this?

186
00:13:46,000 --> 00:13:49,000
This is my own implementation of threat factory interface.

187
00:13:50,000 --> 00:13:55,000
For the sake of the demo, I decided to keep all types in one demo file to not navigate between the

188
00:13:55,000 --> 00:13:58,000
multiple files of one example.

189
00:13:58,000 --> 00:14:01,000
And here I implemented Nusrat Masset.

190
00:14:01,000 --> 00:14:02,000
But why?

191
00:14:02,000 --> 00:14:08,000
We need to override process of threat creation and control it is the motivation to implement custom

192
00:14:08,000 --> 00:14:10,000
sweat factory is different.

193
00:14:10,000 --> 00:14:14,000
You may need to perform some additional actions before creating a threat.

194
00:14:14,000 --> 00:14:20,000
We need to create demon stress or for the debugging purposes, you need to name threats in a different

195
00:14:20,000 --> 00:14:21,000
way than mine.

196
00:14:21,000 --> 00:14:22,000
The different cases.

197
00:14:22,000 --> 00:14:25,000
Why you want to control process of threat creation.

198
00:14:26,000 --> 00:14:28,000
So you implemented a new threat.

199
00:14:28,000 --> 00:14:30,000
Massive in this case.

200
00:14:30,000 --> 00:14:33,000
I want to name threats for a different point.

201
00:14:33,000 --> 00:14:40,000
You can see that I created atomic integer counter and threats by adding value of my counter, incrementing

202
00:14:40,000 --> 00:14:41,000
it afterwards.

203
00:14:42,000 --> 00:14:42,000
That's it.

204
00:14:43,000 --> 00:14:51,000
Now, I said the same number of tasks I have for threats in goal and four tasks each task brings.

205
00:14:51,000 --> 00:14:55,000
Threatening to consult you can submit is a callable or runnable.

206
00:14:56,000 --> 00:14:58,000
Don't pay attention to a new threat.

207
00:14:58,000 --> 00:15:00,000
Must be acceptant Runnable.

208
00:15:00,000 --> 00:15:05,000
This is not directly connected in new executer you create a threat.

209
00:15:06,000 --> 00:15:12,000
Threats are created during the executive servicing utilization in this case and once threats are created,

210
00:15:13,000 --> 00:15:16,000
I submit tasks that will be implemented by these threats.

211
00:15:17,000 --> 00:15:20,000
Tasks may be easier of type runnable or callable.

212
00:15:20,000 --> 00:15:22,000
I keep command here.

213
00:15:22,000 --> 00:15:24,000
Example with Kobel task submission.

214
00:15:25,000 --> 00:15:29,000
Just in case you would like to uncommented and try once you would get the source code.

215
00:15:30,000 --> 00:15:35,000
Let's run this example and in console you might see the threats are different from default.

216
00:15:36,000 --> 00:15:41,000
This proves that Masset of the threat factor was used to create threats in the threat pool.

217
00:15:42,000 --> 00:15:42,000
Is that clear?

218
00:15:43,000 --> 00:15:44,000
Great.

219
00:15:44,000 --> 00:15:46,000
Let's move on now.

220
00:15:46,000 --> 00:15:49,000
Let's look at all the implementations of executive service interface.

221
00:15:50,000 --> 00:15:56,000
Probably remember that when we just first time created executive service, I used cached thread pool.

222
00:15:56,000 --> 00:16:00,000
Let's investigate this one in the source code of executive class.

223
00:16:00,000 --> 00:16:08,000
You can see that when I call New Castrato, I also creates red radical executer just with different

224
00:16:08,000 --> 00:16:08,000
arguments.

225
00:16:09,000 --> 00:16:16,000
So as you may already understand, these mass return us different versions of pre configure thread Thredbo

226
00:16:16,000 --> 00:16:19,000
executer to understand better.

227
00:16:19,000 --> 00:16:23,000
What is the difference between cash Stratego and fix reticle.

228
00:16:23,000 --> 00:16:29,000
Let's compare constructor arguments that are used during the initialization of threat to execute executer

229
00:16:29,000 --> 00:16:29,000
object.

230
00:16:30,000 --> 00:16:35,000
You can see that in cash streetball first two arguments are zero and max integer.

231
00:16:36,000 --> 00:16:40,000
These arguments are responsible to set Corpuz size and maximum pool size.

232
00:16:41,000 --> 00:16:43,000
What is Corpuz size does.

233
00:16:43,000 --> 00:16:47,000
This is a number of threats to keep in the pool, even if they're idle.

234
00:16:47,000 --> 00:16:53,000
How it is different from fixed threat pool infix threat pool equate specific number of threats.

235
00:16:53,000 --> 00:16:56,000
The number ipass as method argument is a.

236
00:16:56,000 --> 00:17:03,000
Plus size and the maximum size, the argument is a keep a lifetime when the number of threats is greater

237
00:17:03,000 --> 00:17:04,000
than the core.

238
00:17:04,000 --> 00:17:11,000
This is the maximum time that excess idle threats will wait for new tasks before terminated.

239
00:17:11,000 --> 00:17:14,000
We can see that they keep a lifetime in cash.

240
00:17:14,000 --> 00:17:18,000
Pool is 60 seconds and infix threat pools.

241
00:17:18,000 --> 00:17:20,000
This value is zero milliseconds.

242
00:17:20,000 --> 00:17:25,000
And the first argument is a cue that is used to store tasks before they're executed.

243
00:17:26,000 --> 00:17:31,000
We can see that in cash throughout threat pool, we use synchronous cue and then fixed threat pool.

244
00:17:31,000 --> 00:17:38,000
We use link, lock and key to what conclusion we may do based on these constructor arguments, these

245
00:17:38,000 --> 00:17:39,000
arguments.

246
00:17:39,000 --> 00:17:46,000
This means that the Casarett pool might grow without bounds to accommodate any number of submitted tasks.

247
00:17:46,000 --> 00:17:53,000
But when the threats are not needed anymore, they will be disposed of after 60 seconds of inactivity

248
00:17:53,000 --> 00:17:55,000
when it might be useful.

249
00:17:55,000 --> 00:18:01,000
For example, when we have a lot of shirtsleeve and tasks in application in a synchronous queue, each

250
00:18:01,000 --> 00:18:05,000
in search operation must wait for a corresponding remove operation.

251
00:18:06,000 --> 00:18:12,000
So we can say that pairs of insert and remove operations always occur simultaneously.

252
00:18:12,000 --> 00:18:15,000
That means that the queue never actually contains.

253
00:18:15,000 --> 00:18:18,000
Annison is as good for most cases.

254
00:18:18,000 --> 00:18:24,000
As I said before, it is good in case we have a lot of shirtsleeve and tasks, but this is not always

255
00:18:24,000 --> 00:18:24,000
the case.

256
00:18:25,000 --> 00:18:31,000
In other cases, using of threat cached pool may impact performance of our application in case with

257
00:18:31,000 --> 00:18:32,000
cash streetball.

258
00:18:32,000 --> 00:18:39,000
Each new task will create a new threat if all existing threats are busy and and reflect potential issues

259
00:18:39,000 --> 00:18:43,000
that might happen during the high load where you have to fix pool.

260
00:18:43,000 --> 00:18:50,000
In the best case, we may get a reservation situation at worst out of memory error.

261
00:18:50,000 --> 00:18:55,000
This is something that you need to consider when you decide to use pre configured threat pool executer

262
00:18:55,000 --> 00:18:58,000
created by new Casarett Pool Factory MassArt.

263
00:18:59,000 --> 00:19:04,000
Let's look at example now I open cash thread pool demo file here.

264
00:19:04,000 --> 00:19:08,000
We have similar example to one we have in the fixed thread pool demo file.

265
00:19:08,000 --> 00:19:15,000
The only difference is that I use different factor Massud from executor's class I call new cache streetball

266
00:19:15,000 --> 00:19:15,000
method.

267
00:19:16,000 --> 00:19:20,000
I submit for tasks and print, pool size and size.

268
00:19:20,000 --> 00:19:27,000
And as we expected, pool size will be equal to the number of submitted tasks in this case because each

269
00:19:27,000 --> 00:19:29,000
thread has leape inside.

270
00:19:30,000 --> 00:19:37,000
And by the moment new task is submitted, there are no available threats and new threat is created and

271
00:19:37,000 --> 00:19:43,000
queue size will be equal to zero because we are synchronous queue inside the threat to execute.

272
00:19:43,000 --> 00:19:44,000
Does it make sense?

273
00:19:45,000 --> 00:19:52,000
And also there is a factory method that takes threat factor as method argument so you can use it when

274
00:19:52,000 --> 00:19:52,000
needed.

275
00:19:53,000 --> 00:19:53,000
That's it.

276
00:19:53,000 --> 00:19:58,000
Regarding the cash threat pool, let's continue the next factory method.

277
00:19:58,000 --> 00:20:05,000
Probably not worse for a separate demo you can call new single thread executer this massive returns

278
00:20:05,000 --> 00:20:08,000
and executive service that manages one thread.

279
00:20:09,000 --> 00:20:15,000
If this single thread terminates due to a failure during the execution prior to shutdown, a new one

280
00:20:15,000 --> 00:20:19,000
will take its place if needed to execute subsequent tasks.

281
00:20:19,000 --> 00:20:26,000
Tasks are guaranteed to execute sequentially, and no more than one task will be active at any given

282
00:20:26,000 --> 00:20:26,000
time.

283
00:20:27,000 --> 00:20:34,000
Additionally, this Red Bull executer is decorated with an immutable wrapper so it can be reconfigured

284
00:20:34,000 --> 00:20:35,000
after creation.

285
00:20:36,000 --> 00:20:38,000
Let's return now skinless Red Bull.

286
00:20:38,000 --> 00:20:45,000
Executer we have to factor masses in executor's class that allows us to create executor's service of

287
00:20:45,000 --> 00:20:49,000
this type ZAYA News kidlets red pool within the parameters.

288
00:20:49,000 --> 00:20:55,000
It describes a number of course, threads and overloaded masses that takes that factory as an additional

289
00:20:55,000 --> 00:20:57,000
argument in the source code.

290
00:20:57,000 --> 00:21:00,000
We can use it on an instance of scandals.

291
00:21:00,000 --> 00:21:02,000
Reppel exactly the type.

292
00:21:02,000 --> 00:21:05,000
Let's open it and investigate this type.

293
00:21:05,000 --> 00:21:13,000
As we can see from the time declaration, it extends red executer and implements kidlet executive service

294
00:21:13,000 --> 00:21:17,000
interface, which in turn extends executive service interface.

295
00:21:18,000 --> 00:21:22,000
We need to understand what new behavior is introduced by scheduled executive service.

296
00:21:23,000 --> 00:21:30,000
Basically for new methods are introduced on Vermonter's cattle methods it takes is a random object.

297
00:21:31,000 --> 00:21:35,000
This method allows us to run a task once after a specified delay.

298
00:21:36,000 --> 00:21:43,000
Also cattle at fixed rate mass that allows us to run a task after a specified initial delay and then

299
00:21:43,000 --> 00:21:46,000
run it repeatedly with a certain period.

300
00:21:46,000 --> 00:21:51,000
The period argument is a time measured between the starting times of the tasks.

301
00:21:51,000 --> 00:21:53,000
So the execution rate is fixed.

302
00:21:54,000 --> 00:21:56,000
Schedule was fixed, the.

303
00:21:56,000 --> 00:22:02,000
A.M. is similar to scheduled at a fixed rate in that it would be the difference as a given task, but

304
00:22:02,000 --> 00:22:09,000
the specified delay is measured between the end of the previous task and start of the next task.

305
00:22:09,000 --> 00:22:14,000
Its execution rate may vary depending on the time it takes to run any given task.

306
00:22:15,000 --> 00:22:20,000
Let's open skidoos, read to them clause to review, quote, examples with this executer.

307
00:22:21,000 --> 00:22:26,000
The first example just shows us how to execute some task after initial delay.

308
00:22:27,000 --> 00:22:30,000
I create executer calls Macit.

309
00:22:30,000 --> 00:22:34,000
I just want to bring threatening to cancel after one second delay.

310
00:22:34,000 --> 00:22:36,000
This all tasks that I want to schedule.

311
00:22:37,000 --> 00:22:39,000
Let's run this program in console.

312
00:22:39,000 --> 00:22:42,000
We can see that threatening has been printed.

313
00:22:42,000 --> 00:22:46,000
This is how simple you must kill task for execution.

314
00:22:46,000 --> 00:22:54,000
Now I open scattered pull them two in this file we have them off schedule at fixed rate and schedule.

315
00:22:54,000 --> 00:22:59,000
With delay I create executer and then Wolk's cattle at fixed rate.

316
00:22:59,000 --> 00:23:06,000
Initial delay is five hundred milliseconds and after that start of each new task in each one second

317
00:23:07,000 --> 00:23:11,000
after seven seconds waiting, we shut down our executive service.

318
00:23:12,000 --> 00:23:18,000
I printer separator here and after that I create new executer and then walks schedule with a fixed delay.

319
00:23:19,000 --> 00:23:25,000
I am going to run the program and I'd like you pay attention to the fact that these two masses will

320
00:23:25,000 --> 00:23:32,000
work slightly differently because they track the same interval a little bit differently from start of

321
00:23:32,000 --> 00:23:40,000
one task to start of another task and from finish off one task to start off another task, I intentionally

322
00:23:40,000 --> 00:23:42,000
added sleep in each task.

323
00:23:42,000 --> 00:23:49,000
In this case, we may notice how in the first case, new task is executed each second, and in the second

324
00:23:49,000 --> 00:23:57,000
case, each task is executed approximately one and a half second because interval is measured between

325
00:23:57,000 --> 00:24:00,000
end of the one task and start of another task.

326
00:24:00,000 --> 00:24:02,000
And each task has sleep inside.

327
00:24:03,000 --> 00:24:07,000
I run the program and you can watch the result and feel the difference.

328
00:24:08,000 --> 00:24:09,000
Can you see the difference?

329
00:24:10,000 --> 00:24:15,000
Hope that with this example it is clear HouseCalls Reticule executive works.

330
00:24:15,000 --> 00:24:21,000
Also, we have similar factory method, but just for executer with one thread you can use three single

331
00:24:21,000 --> 00:24:24,000
threads candidate executive factory method to create similar.

332
00:24:24,000 --> 00:24:26,000
Executer was one thread.

333
00:24:26,000 --> 00:24:32,000
You can see that there is a wrapper here that exposes only the scheduled executive service methods of

334
00:24:32,000 --> 00:24:38,000
a scheduled executive service implementation and service over overloaded method that takes threat factor

335
00:24:38,000 --> 00:24:45,000
as method argument removed almost all factory methods to create different executive services.

336
00:24:45,000 --> 00:24:51,000
We still need to learn for doing framework to understand how, for example, works.

337
00:24:52,000 --> 00:24:56,000
That's why we'll review new works to improve Masset in the next lesson.

338
00:24:56,000 --> 00:24:57,000
That's it for today.

339
00:24:58,000 --> 00:25:01,000
Let's review what we have learned today in this lesson.

340
00:25:01,000 --> 00:25:05,000
In this lesson, we learn different implementations of executive services.

341
00:25:06,000 --> 00:25:11,000
We learn thread pool, executive class and how to create a fixed threat pool and cache threat pool.

342
00:25:12,000 --> 00:25:16,000
Now, you know the difference in these pro configurator threat pools.

343
00:25:16,000 --> 00:25:22,000
Also, you know the formula and the rules that will help you to calculate the ideal number of threats

344
00:25:22,000 --> 00:25:24,000
to create in the threat pool.

345
00:25:24,000 --> 00:25:28,000
Also, we learned how to work with threat factory after this lesson.

346
00:25:28,000 --> 00:25:32,000
You know how to work with a single threat pool and scandalous threat pool.

347
00:25:32,000 --> 00:25:35,000
Executer that's all what I have for you for this lesson.

348
00:25:36,000 --> 00:25:37,000
Thanks a lot for your attention.

349
00:25:38,000 --> 00:25:40,000
Have a great day and see you in the next lesson.