1
00:00:00,210 --> 00:00:00,810
Bienvenidos.

2
00:00:00,840 --> 00:00:02,340
Continuamos con el Dreadful.

3
00:00:02,400 --> 00:00:08,540
Ejecutor Bueno, justamente lo que retorna este método, el Fixed Dredd Pool, una instancia de un tried

4
00:00:08,580 --> 00:00:09,760
pool executar.

5
00:00:09,900 --> 00:00:14,880
Bueno, acá utilizamos el tipo de la interfaz, pero la implementación concreta en la que tenemos acá

6
00:00:15,000 --> 00:00:22,350
un control click para ver el método y acá retorna una instancia New Dredd Pool executar que maneja varios

7
00:00:22,350 --> 00:00:22,920
parámetros.

8
00:00:23,100 --> 00:00:29,190
Bueno, argumento en el método, por ejemplo el Corpus 6, que es el tamaño del pool por defecto, es

9
00:00:29,190 --> 00:00:34,440
decir, el tamaño principal, por eso se llama KOR principal cantidad de dirig que va a manejar por

10
00:00:34,440 --> 00:00:34,890
defecto.

11
00:00:35,070 --> 00:00:40,440
Pero también podemos pasar como segundo argumento un maximum pull size que sería como el tamaño máximo

12
00:00:40,440 --> 00:00:42,150
que podría tener el pull claro.

13
00:00:42,210 --> 00:00:48,060
Por ejemplo, si el tamaño del core ya está todo ocupado y tenemos varias tareas en espera, podríamos

14
00:00:48,060 --> 00:00:55,230
ampliar a un máximo pull pussys a un valor máximo y ahí pueden entrar en ejecución más tarea en el ejecutor.

15
00:00:55,320 --> 00:01:01,110
Por lo tanto, se amplía el tamaño del pool, la cantidad de dirigid disponible, pero también tiene

16
00:01:01,200 --> 00:01:03,270
una limitación que te exeso de cantidad.

17
00:01:03,360 --> 00:01:08,790
Es decir, si restamos el corpus 6 con el máximo, ahí tenemos un delta, un exceso.

18
00:01:08,850 --> 00:01:14,350
Este exceso de pull se podrían eliminar después de un tiempo de inactividad, es decir, cuando estos

19
00:01:14,350 --> 00:01:21,210
Dorit entran en un tiempo de inactividad o ya no se estén utilizando, se eliminan del pool y el pull

20
00:01:21,240 --> 00:01:22,260
vuelve a un tamaño menor.

21
00:01:22,360 --> 00:01:29,100
Se fija entonces flexible, solamente se mantiene como un delta por sobre el color pussys y en el atributo

22
00:01:29,160 --> 00:01:31,180
queda el tipo long keep alive time.

23
00:01:31,380 --> 00:01:37,280
Acá colocamos según la unidad tiempo que especificamos con el tam juny como cuarto argumento, ya sea

24
00:01:37,290 --> 00:01:43,200
minuto, segundo milisegundo, colocamos la cantidad de tiempo que puede estar e inactividad antes de

25
00:01:43,200 --> 00:01:46,530
que se eliminen, pero ojo, solamente se eliminan el delta.

26
00:01:46,650 --> 00:01:48,810
La diferencia entre el score y el máximo.

27
00:01:48,900 --> 00:01:51,360
Bien, volvamos acá a esta clase.

28
00:01:51,660 --> 00:01:56,700
Bueno, el fixed de Red Bull se llama fixed por fijo, es un tamaño fijo del pull.

29
00:01:56,760 --> 00:02:01,620
Por lo tanto, la cantidad del kor es idéntica a la del máximo.

30
00:02:01,740 --> 00:02:04,200
El máximo es igual al tamaño del pool.

31
00:02:04,440 --> 00:02:07,470
No va a existir un tal tan no se va a ampliar, es fijo.

32
00:02:07,590 --> 00:02:12,510
Por lo tanto, también el tiempo de inactividad es cero, ya que no hay una diferencia, no hay un delta

33
00:02:12,690 --> 00:02:19,110
y en esta lista enlazada que vemos acá se van a guardar los elementos en la cola en espera.

34
00:02:19,350 --> 00:02:20,490
Bien, veamos algunos ejemplos.

35
00:02:20,610 --> 00:02:21,750
Vamos a cerrar acá.

36
00:02:22,440 --> 00:02:28,230
Entonces este retorna una instancia concreta, pero acá usamos el tipo de la interfaz, pero podríamos

37
00:02:28,230 --> 00:02:29,790
cambiar al tipo concreto.

38
00:02:30,060 --> 00:02:32,340
Por ejemplo Dreadful executar.

39
00:02:35,250 --> 00:02:37,410
Acá tenemos que hacer un cast sobre el error.

40
00:02:37,440 --> 00:02:44,070
Colocamos Cast adrid, pool ejecutor perfecto y acá tenemos métodos donde podemos afinar configuraciones

41
00:02:44,070 --> 00:02:44,640
parámetro.

42
00:02:44,790 --> 00:02:49,320
Como ya vimos, podrían personalizar con el método set o sobrescribir el corpus.

43
00:02:49,350 --> 00:02:55,680
Sigue el tamaño del pool, el máximo pussys, el tamaño máximo que eventualmente podría tener el pool

44
00:02:55,890 --> 00:03:03,750
y también el tiempo en que podría estar este delta o acceso de grid cuando están en inactividad, por

45
00:03:03,750 --> 00:03:05,580
ejemplo punto set.

46
00:03:05,730 --> 00:03:13,680
Acá tenemos todos los set corpus saes el tiempo y la unidad de tiempo set keep alive time y el maximum

47
00:03:13,740 --> 00:03:16,650
pussys bien, pero lo dejamos por defecto así como está.

48
00:03:16,770 --> 00:03:21,690
De todas forma, esto se puede personalizar, customizar a nuestra medida según necesitemos.

49
00:03:22,350 --> 00:03:25,110
Pero también tenemos otro método interesante que vamos a ver.

50
00:03:25,320 --> 00:03:26,970
Por ejemplo Shout.

51
00:03:27,240 --> 00:03:40,320
Vamos a imprimir tamaño del pool bien executar punto get pussys el tamaño del pool actual, que podría

52
00:03:40,320 --> 00:03:46,260
ser una combinación entre el core y el máximo, recuerda que el máximo es el tope que eventualmente

53
00:03:46,260 --> 00:03:47,850
podría tener el pool.

54
00:03:48,000 --> 00:03:49,200
El core es la base.

55
00:03:49,350 --> 00:03:52,710
Si son iguales, sería un tamaño fijo, tal como lo tenemos acá.

56
00:03:53,490 --> 00:03:57,210
Entonces vamos a invocar el GET por seis, el tamaño actual.

57
00:04:00,950 --> 00:04:04,970
Cantidad de vivir o más que diría tareas

58
00:04:07,940 --> 00:04:15,020
en cola executar punto Geet quew o la cola.

59
00:04:17,970 --> 00:04:19,150
Punto 6.

60
00:04:19,410 --> 00:04:20,290
Qué sería el tamaño?

61
00:04:21,000 --> 00:04:24,630
Y esto mismo lo vamos a copiar porque bueno, acá debería ser cero.

62
00:04:25,080 --> 00:04:28,420
Por qué no hemos agregado ninguna tarea al ejecutor?

63
00:04:29,160 --> 00:04:36,020
Pero por ejemplo, si lo colocamos acá antes del chat down y después de haber agregado tareas, qué

64
00:04:36,030 --> 00:04:36,600
va a mostrar?

65
00:04:36,690 --> 00:04:40,560
Bueno, el tamaño lo tenemos como fijo de dos, pero tenemos tres tarea.

66
00:04:40,800 --> 00:04:44,670
Entonces diría mostrar tamaño del pull 2 y encola 1.

67
00:04:45,030 --> 00:04:45,190
Bueno.

68
00:04:46,140 --> 00:04:47,250
Entonces vamos a levantar.

69
00:04:52,810 --> 00:04:53,560
Vamos a revisar.

70
00:04:54,010 --> 00:04:55,780
Entonces, cuando parte cero, cero.

71
00:04:55,840 --> 00:04:56,440
Perfecto.

72
00:04:56,890 --> 00:05:01,540
Y después también modulpool 2 cantidad de tareas en cola 1.

73
00:05:02,230 --> 00:05:03,130
Hay 2 y 1.

74
00:05:03,790 --> 00:05:07,690
Ahora, qué pasa si ampliamos acá a 1 1 solo?

75
00:05:11,050 --> 00:05:12,280
Bueno, primero hacer cero cero.

76
00:05:12,470 --> 00:05:13,060
Eso está claro.

77
00:05:19,610 --> 00:05:24,770
Acá se muere un poco más porque está ejecutando los tres de forma secuencial.

78
00:05:25,340 --> 00:05:25,820
Veamos.

79
00:05:26,210 --> 00:05:27,140
Cero, cero.

80
00:05:27,260 --> 00:05:32,270
También el pull uno, pero cantidad de tareas en cola dos, porque son tres tarea, una en ejecución

81
00:05:32,330 --> 00:05:33,440
y dos esperando.

82
00:05:34,400 --> 00:05:39,350
Si colocamos 3, bueno base 3 y 0 en cola.

83
00:05:47,520 --> 00:05:49,350
Se fijan el tamaño del pull 3.

84
00:05:49,740 --> 00:05:53,250
Buscamos cantidad, tareas en cola 0, bien.

85
00:05:53,340 --> 00:06:00,390
Y para finalizar este video vamos a ver un ejemplo del productor y consumidor, utilizando también esto

86
00:06:00,390 --> 00:06:04,920
mismo que hemos estado viendo bien, esto lo podemos tal como estaba antes o lo dejamos así?

87
00:06:05,010 --> 00:06:05,650
Da lo mismo.

88
00:06:05,760 --> 00:06:11,190
Pero recuerden, podemos hacer el cast adrid pull sigue utor para poder tener acceso a estos métodos

89
00:06:11,190 --> 00:06:13,020
get y también método set.

90
00:06:13,110 --> 00:06:14,850
Poder modificar estos parámetros.

91
00:06:15,000 --> 00:06:18,330
O bien incluso podemos crear la instancia directamente del Drizzt Pool.

92
00:06:18,420 --> 00:06:23,790
Executar también y pasando al constructor los parámetros ya sea el corpus.

93
00:06:23,790 --> 00:06:31,290
Sois el máximo pulsares y el parámetro de tiempo para mantener vivos estos que están inactivos.

94
00:06:31,350 --> 00:06:36,690
Por ejemplo, que después de tanto milisegundo de inactividad que se eliminen del pool.

95
00:06:37,380 --> 00:06:38,400
Bien, veamos el ejemplo.

96
00:06:38,430 --> 00:06:42,300
Entonces vamos a copiar este de acá, lo pegamos acá.

97
00:06:44,170 --> 00:06:49,990
Ejemplo Seki Utor, productor consumidor.

98
00:06:51,190 --> 00:06:51,580
Ok.

99
00:06:54,320 --> 00:06:59,120
Estoy acá, lo cerramos y usamos este nomás, pero en realidad el ejemplo es bien simple, porque la

100
00:06:59,120 --> 00:07:00,080
tarea ya la tenemos.

101
00:07:02,240 --> 00:07:04,750
Le quitamos esto y lo vamos a reutilizar.

102
00:07:06,870 --> 00:07:11,550
Lo podremos mantener el chotano, por supuesto, y todo lo que está acá lo quitamos.

103
00:07:12,090 --> 00:07:12,830
Lo eliminamos.

104
00:07:17,410 --> 00:07:19,120
Recuerden que son dos tareas, nada más.

105
00:07:21,690 --> 00:07:23,970
Y son del tipo razonable.

106
00:07:24,000 --> 00:07:25,320
Por lo tanto, no retorna nada.

107
00:07:25,500 --> 00:07:31,610
Entonces, futuro uno acá vamos a pasar una tarea.

108
00:07:31,650 --> 00:07:32,400
Pero qué tarea?

109
00:07:32,670 --> 00:07:40,980
Recuerden panadería P Igual New Panadería es el monitor o recurso compartido.

110
00:07:42,120 --> 00:07:46,170
Vamos a tener un renegaban productor yo seré el panadero.

111
00:07:46,470 --> 00:07:49,500
Igual ni un panadero.

112
00:07:49,590 --> 00:07:52,320
Acá tengo que pasar la panadería.

113
00:07:54,570 --> 00:08:02,280
Otro más consumidor consumidor también pasaba a la panadería.

114
00:08:03,280 --> 00:08:03,450
Bien.

115
00:08:03,720 --> 00:08:05,580
Y dos tareas vamos a pasar.

116
00:08:05,580 --> 00:08:07,020
Productor o consumidor?

117
00:08:07,030 --> 00:08:07,980
Primero de lo mismo.

118
00:08:08,520 --> 00:08:11,730
Vamos a copiar y pegamos.

119
00:08:11,820 --> 00:08:13,710
Y pasamos ahora un consumidor.

120
00:08:14,640 --> 00:08:15,300
Y acá a futuro.

121
00:08:15,300 --> 00:08:15,630
2.

122
00:08:17,480 --> 00:08:22,930
De hecho, podríamos traja con estos futuros, saber si están trabajando y Down lo podemos cancelar

123
00:08:22,940 --> 00:08:25,850
también lo que queramos y listo.

124
00:08:25,910 --> 00:08:32,090
Ahí está el ejemplo, súper simple, pero cuidado, al menos como son dos tarea que está sincronizada,

125
00:08:32,180 --> 00:08:36,950
trabajan al mismo tiempo, tienen que tener un pool, un tamaño del pulpo, lo menos de 2 mínimo de

126
00:08:36,950 --> 00:08:42,080
2 para que sepan ejecutar estas dos al mismo tiempo y pueden trabajar con él panadería.

127
00:08:42,200 --> 00:08:46,700
Con este recurso compartido, este monitor listo, ejecutamos.

128
00:08:49,400 --> 00:08:56,300
Dé comienzo en orden se fijan sincronizado, mismo ejemplo que vimos, pero llevado a un estricto service

129
00:08:56,450 --> 00:09:04,430
a este Frenkel y finaliza No podría tener un Poul de uno no, porque se ejecutaría uno solo primero,

130
00:09:04,550 --> 00:09:10,070
pero quería esperando eternamente a que el siguiente lo consuma, pero el siguiente no se está ejecutando

131
00:09:10,190 --> 00:09:11,960
porque está en la cola, se fijan?

132
00:09:12,040 --> 00:09:15,110
Entonces tiene que ser de por lo menos dos o más.

133
00:09:23,870 --> 00:09:24,770
Eso viene, por tanto.

134
00:09:31,900 --> 00:09:34,340
Bueno, y hoy finaliza Ni todo sincronizado.

135
00:09:34,610 --> 00:09:38,980
Si el panadero hornea, te consume y siempre Panero parte primero.

136
00:09:39,070 --> 00:09:45,820
El cliente no puede consumir si tuyo no existe ningún pan, incluso si acá colocamos consumidor acá

137
00:09:45,910 --> 00:09:51,040
y productor acá para que eventualmente parta el primer consumidor, no importa.

138
00:09:51,070 --> 00:09:54,880
El consumidor bate que esperar a que el productor desarrolle.

139
00:09:54,970 --> 00:09:56,200
Horneé algún pan.

140
00:09:58,660 --> 00:10:00,040
Siempre el panadero primero.

141
00:10:00,790 --> 00:10:01,010
Bien.

142
00:10:01,450 --> 00:10:02,520
Tamaño del pulsera.

143
00:10:02,590 --> 00:10:04,830
Cantidad de tarea en cola zero acá.

144
00:10:05,050 --> 00:10:11,020
Luego creamos las dos tareas Ravell las asignamos al exigi Outer con submit y ahora cambia el tamaño

145
00:10:11,020 --> 00:10:11,770
del pool.

146
00:10:11,860 --> 00:10:14,740
2 cantidad tareas en cola 0.

147
00:10:15,610 --> 00:10:22,780
Y esto sería solamente faltaría la siguiente clases trabajar con tarea programada utilizando por ejemplo

148
00:10:23,050 --> 00:10:29,200
por acá lo tenemos el New News Dodge Dreadful, por ejemplo, o con Finkel por acá tenemos también el

149
00:10:29,200 --> 00:10:36,370
finkel dret squeda alt también con uno solo o con más de uno s con un pool de Dredd.

150
00:10:38,140 --> 00:10:40,450
Bien, acá alojamos en 2 y estamos listo.

151
00:10:40,540 --> 00:10:42,310
Continuamos en la siguiente clase.
