Gepufferter / ungepufferter Kanal

8

Könnte jemand erklären, warum das Programm nicht mit einem fatal_error beendet wird, wenn der Kanal gepuffert ist?

Ungepufferter Kanal

%Vor%

Gepufferter Kanal

%Vor%

Danke!

    
accurate respondetur 11.01.2014, 20:52
quelle

3 Antworten

11

Das Schreiben in einen gepufferten Kanal blockiert nicht, wenn im Puffer Platz ist.

Wenn Sie versuchen, zwei Elemente mit einer Puffergröße von eins in den Kanal zu stellen, erhalten Sie denselben Fehler:

%Vor%

gibt Ihnen:

%Vor%     
Sean 11.01.2014 21:04
quelle
2

Es ist ein Kernkonzept von Gos Kanälen (oder anderen CSP Implementierungen wie Clojures core.async Bibliothek), die sie blockieren. Im Allgemeinen gibt es, wie Sie bereits erwähnt haben, zwei Arten von Kanälen:

  • gepuffert die blockiert, wenn der Puffer voll ist.
  • ungepuffert was blockiert, wenn es kein "Rendezvous" gibt, d. h. es muss jemand geben ( c <- ) und jemanden, der ( <- c ) aus dem Kanal nimmt.

In Ihrem speziellen Fall ist die Go-Laufzeit intelligent genug, um zu erkennen, dass niemand 3 vom Kanal c übernimmt. Daher ist es ein Deadlock und (Gott sei Dank) wird ein Fehler ausgelöst.

Was Sie normalerweise tun, wenn Sie mit Channels arbeiten, ist goroutines (checkout diese Einführung ), die einen von der Go-Runtime verwalteten Lightweight-Thread erzeugen, um den Body gleichzeitig auszuführen:

%Vor%     
beatngu13 24.06.2016 19:47
quelle
1

Danke @Matt

Ich fand die Antwort in diesem Beitrag Wie funktioniert make (chan bool) verhält sich anders als make (chan bool, 1)? :

Actually that's the reason why your problem is generated. Un-buffered channels are only writable when there's someone blocking to read from it, which means you shall have some coroutines to work with -- instead of this single one.

    
accurate respondetur 12.01.2014 02:29
quelle

Tags und Links