go - link - listas de canales movistar
Cuándo usar un canal almacenado? (5)
¿Cuáles son los casos de uso para los canales almacenados? Si quiero múltiples acciones paralelas, podría usar el eq del canal síncrono predeterminado.
package main
import "fmt"
import "time"
func longLastingProcess(c chan string) {
time.Sleep(2000 * time.Millisecond)
c <- "tadaa"
}
func main() {
c := make(chan string)
go longLastingProcess(c)
go longLastingProcess(c)
go longLastingProcess(c)
fmt.Println(<- c)
}
¿Cuáles serían los casos prácticos para aumentar el tamaño del búfer?
En general, el almacenamiento en búfer en los canales es beneficioso por razones de rendimiento.
Si un programa se diseña utilizando un enfoque de flujo de eventos o flujo de datos, los canales proporcionan los medios para que los eventos pasen de un proceso a otro (utilizo el término proceso en el mismo sentido que en los Procesos secuenciales de comunicación (CSP) de Tony Hoare , es decir, efectivamente sinónimo de la goroutine ).
Hay momentos en los que un programa necesita que sus componentes permanezcan sincronizados en pasos de bloqueo. En este caso, se requieren canales sin búfer.
De lo contrario, generalmente es beneficioso agregar almacenamiento en búfer a los canales. Esto debería verse como un paso de optimización (aún puede haber un punto muerto si no está diseñado).
Hay nuevas estructuras de aceleración posibles gracias al uso de canales con pequeños amortiguadores (por ejemplo ).
Hay formas especiales de sobreescritura o con pérdida de canales utilizados en occam y jcsp para solucionar el caso especial de un ciclo (o ciclo) de procesos que de otro modo probablemente se estancarían. Esto también es posible en Go al escribir un buffer de sobretitulación de goroutine ( ejemplo ).
Nunca debe agregar almacenamiento en búfer simplemente para arreglar un punto muerto. Si el programa se bloquea, es mucho más fácil de solucionar al comenzar con cero almacenamiento en búfer y pensar en las dependencias. Luego agregue almacenamiento en búfer cuando sepa que no se estancará.
Puede construir goroutines composicionalmente, es decir, un goroutine puede contener goroutines. Esta es una característica de CSP y beneficia enormemente la escalabilidad. Los canales internos entre un grupo de goroutines no son de interés cuando se diseña el uso externo del grupo como un componente autónomo. Este principio se puede aplicar repetidamente a escalas cada vez mayores.
Es una pregunta difícil, porque el programa es incorrecto: sale después de recibir una señal de un administrador de rutina, pero se iniciaron tres. Buffering the channel no lo hace diferente.
EDITAR: Por ejemplo, aquí hay un poco de discusión general sobre los buffers de canal. Y algo de ejercicio . Y un capítulo del libro sobre lo mismo.
Los canales almacenados en el búfer no bloquean al remitente mientras haya espacio. Esto puede aumentar la capacidad de respuesta y el rendimiento.
Enviar varios elementos en un canal en búfer se asegura de que se procesen en el orden en que se enviaron.
De Effective Go (con el ejemplo): " Un canal almacenado puede usarse como un semáforo, por ejemplo para limitar el rendimiento " .
En general, hay muchos casos de uso y patrones de uso del canal, por lo que esta no es una respuesta exhaustiva.
Para dar un solo caso de uso un poco más concreto:
Supongamos que quiere que su canal represente una cola de tareas, de modo que un planificador de tareas pueda enviar trabajos a la cola y un hilo de trabajo pueda consumir un trabajo al recibirlo en el canal.
Supongamos además que, aunque en general usted espera que cada trabajo sea manejado de manera oportuna, le lleva más tiempo al trabajador completar una tarea que al planificador programarlo.
Tener un búfer permite al planificador depositar trabajos en la cola y seguir siendo sensible a la entrada del usuario (o tráfico de red, o lo que sea) porque no tiene que dormir hasta que el trabajador esté listo cada vez que planifica una tarea. En cambio, se ocupa de sus asuntos y confía en que los trabajadores se pongan al día durante un período más tranquilo.
Si desea un ejemplo MÁS CONCRETO sobre una pieza específica de software, entonces veré qué puedo hacer, pero espero que esto satisfaga sus necesidades.
Si el receptor del canal siempre es más lento que el emisor, eventualmente se consumirá un búfer de cualquier tamaño. Eso te dejará con un canal que pausa tu rutina de rutina tan a menudo como un canal sin búfer, por lo que también podrías usar un canal sin búfer.
Si el receptor es típicamente más rápido que el emisor, a excepción de una ráfaga ocasional, un canal amortiguado puede ser útil y la memoria intermedia debe ajustarse al tamaño de la ráfaga típica a la que se puede llegar mediante la medición en tiempo de ejecución.
Como alternativa a un canal almacenado en búfer, es mejor enviar simplemente una matriz o una estructura que contenga una matriz sobre el canal para tratar explosiones / lotes.