Per impostazione predefinita, la comunicazione di goroutine è synchronous e unbuffered: le mandate non vengono completate finché un destinatario non accetta il valore. Ci deve essere un ricevitore pronto a ricevere dati dal canale e quindi il mittente può consegnarlo direttamente al ricevitore.
invio Così canale/ricezione operazioni di bloccare fino a quando l'altro lato è pronto:
1. Un'operazione di invio su un blocchi di canale fino a quando un ricevitore è disponibile per lo stesso canale: se non c'è destinatario per il valore su ch, nessun altro valore può essere inserito nel canale. E viceversa: nessun nuovo valore può essere inviato in ch quando il canale non è vuoto! Quindi l'operazione di invio attenderà fino a quando ch sarà nuovamente disponibile.
2. Un'operazione di ricezione per un blocco di canali finché non è disponibile un mittente per lo stesso canale: se non c'è alcun valore nel canale, il ricevitore si blocca.
Ciò è illustrato nel seguente esempio:
package main
import "fmt"
func main() {
ch1 := make(chan int)
go pump(ch1) // pump hangs
fmt.Println(<-ch1) // prints only 0
}
func pump(ch chan int) {
for i:= 0; ; i++ {
ch <- i
}
}
Poiché non c'è ricevitore si blocca goroutine e stampare solo il primo numero.
Per risolvere questo problema, è necessario definire una nuova goroutine che legge dal canale in un ciclo infinito.
func receive(ch chan int) {
for {
fmt.Println(<- ch)
}
}
Poi nel main():
func main() {
ch := make(chan int)
go pump(ch)
receive(ch)
}
fonte
2015-07-21 13:26:55
condizione Race? È sicuro farlo? –
Sì, certo, è proprio audace quale goroutine ottiene l'elemento. – inf
Non lo chiamerei "race condition". Questo termine è convenzionalmente definito per indicare un comportamento indesiderato a causa di un accesso concorrente non sicuro di una variabile. I canali sono progettati per l'accesso sicuro in contemporanea e non c'è nulla di sbagliato con più lettori su un canale non bufferizzato. – JimB