Am besten Weg mit sync.WaitGroup mit externen Funktion

Ich habe einige Probleme mit dem folgenden code:

package main

import (
"fmt"
"sync"
)
//This program should go to 11, but sometimes it only prints 1 to 10.
func main() {
    ch := make(chan int)
    var wg sync.WaitGroup
    wg.Add(2)
    go Print(ch, wg) //
    go func(){

        for i := 1; i <= 11; i++ {
            ch <- i
        }

        close(ch) 
        defer wg.Done()


    }()

    wg.Wait() //deadlock here
}

//Print prints all numbers sent on the channel.
//The function returns when the channel is closed.
func Print(ch <-chan int, wg sync.WaitGroup) {
    for n := range ch { //reads from channel until it's closed
        fmt.Println(n)
    }
    defer wg.Done()
}

Bekomme ich einen deadlock an der angegebenen Stelle. Ich habe versucht Einstellung wg.Add(1) anstatt 2 und es löst mein problem. Meine überzeugung ist, dass ich nicht erfolgreich, sendet der Kanal als argument für die Printer Funktion. Gibt es eine Möglichkeit, das zu tun? Sonst eine Lösung zu meinem problem ist das ersetzen der go Print(ch, wg)Zeile mit:

go func() {
Print(ch)
defer wg.Done()
}

und die änderung der Printer Funktion:

func Print(ch <-chan int) {
    for n := range ch { //reads from channel until it's closed
        fmt.Println(n)
    }

}

Was ist die beste Lösung?

aus golang.org/pkg/sync er stellt fest: "Werte mit den Typen in diesem Paket sollte nicht kopiert werden" Also, pass nur sync.WaitGroup durch pointer-Referenz.

InformationsquelleAutor Sahand | 2016-04-04

go synchronization

21

Gut, zuerst Ihre eigentliche Fehler ist, dass du gibst die Print Methode eine Kopie der sync.WaitGroup, so dass es nicht zu nennen, die Done() Methode, nach der man Wait()ing auf.

Versuchen Sie dies:
```
package main

import (
    "fmt"
    "sync"
)

func main() {    
    ch := make(chan int)

    var wg sync.WaitGroup
    wg.Add(2)    

    go Print(ch, &wg)

    go func() {  
        for i := 1; i <= 11; i++ {
            ch <- i
        }
        close(ch)
        defer wg.Done()
    }()          

    wg.Wait() //deadlock here
}                

func Print(ch <-chan int, wg *sync.WaitGroup) {
    for n := range ch { //reads from channel until it's closed
        fmt.Println(n)
    }            
    defer wg.Done()
}
```
Nun, wenn Sie Ihre Print Methode zum entfernen der WaitGroup es ist generell eine gute Idee: die Methode braucht nicht zu wissen, etwas abzuwarten, bis er seine Arbeit fertig zu stellen.
- Habe es, ich wusste nicht, Sie brauchte die Adresse gesendet werden, um Print statt der WaitGroup selbst. Ich bin damit einverstanden, dass die Methode braucht nicht zu wissen über die WaitGroup, aber angenommen, ich möchte das auf jeden Fall. Und was hat der Stern zu tun? Es tut pick, die die TATSÄCHLICHEN WaitGrooup ich habe in main? Und warum ist diese nicht eine Kopie?
- Die *sync.WaitGroup sagt dem compiler, den Sie wollen, einen Zeiger auf eine WaitGroup statt einer WaitGroup. Damit der compiler erwartet, dass Sie die Methode aufrufen, indem Sie ihm eine Adresse, damit die &wg.
- Glaube nicht, können Sie entfernen von Druck ist waitgroup als Haupt-wg.Warten, könnten Sie fallen durch, bevor der Letzte Wert wird ausgedruckt, wenn Sie nur darauf wartete, dass die sender zu vervollständigen. Auch kein Grund zum beenden einer Funktion mit einem verschieben wg.Erledigt(), verschieben bedeutet im Grunde genommen, starten Sie dieses am Ende. drop aufschieben
- Diese Antwort zeigt nicht das, was ich denke, ist das richtige pattern, die Elwinar gepostet in den Kommentaren zu einer Antwort unten bei play.golang.org/p/lOopY0bYHT. Print ist verpackt in einem anonymen goroutine in main und wg.Done() ist aufgerufen, zu diesem Anwendungsbereich.
InformationsquelleAutor Elwinar
2

Stimme ich mit @Elwinar die Lösung, dass das größte problem in Ihrem code verursacht wird, indem eine Kopie Ihrer Waitgroup zu den Print Funktion.

Dies bedeutet, dass die wg.Done() betrieben wird, auf einer Kopie des wg Sie in der main. Daher wg im main konnte nicht verringert, und somit ein deadlock passiert, wenn Sie wg.Wait() im main.

Da Ihnen auch Fragen über die beste Praxis, ich konnte Ihnen einige Anregungen für meine eigene:
- Nicht entfernen defer wg.Done() im Print. Da Ihr goroutine in main ist ein sender, und drucken ist ein Empfänger, entfernen wg.Done() in der Empfänger routine verursachen eine unvollendete Empfänger. Dies ist, weil nur Ihr sender ist synchronisiert mit Ihrem Haupt, so nach und nach Ihre sender geschehen ist, Ihr Haupt ist getan, aber es ist möglich, dass der Empfänger noch funktioniert. Mein Punkt ist: nicht verlassen, einige baumelten goroutines um nach deiner main-routine beendet ist. Schließen Sie Sie, oder warten Sie für Sie.
- Daran denken dies zu tun panic recovery überall, vor allem anonyme goroutine. Ich habe gesehen, dass viele golang Programmierer vergessen zu setzen Panik Erholung in goroutines, auch wenn Sie nicht vergessen, wieder in die normalen Funktionen. Es ist kritisch, wenn Sie wollen, dass Ihr code korrekt Verhalten oder zumindest würdevoll, wenn etwas unerwartetes passiert.
- Verwenden defer vor jeder kritische Anrufe, wie sync Verwandte Anrufe, am Anfang, da Sie nicht wissen, wo Sie den code brechen kann. Lassen Sie uns sagen, dass Sie entfernt defer vor wg.Done(), und einen Panik-Auftritt in Ihrer anonymen goroutine in deinem Beispiel. Wenn Sie nicht haben Panik erholt, wird es Panik. Aber was passiert, wenn Sie eine Panik zu erholen? Alles ist in Ordnung jetzt? Nein. Sie erhalten deadlock bei wg.Wait() seit Ihr wg.Done() wird übersprungen, weil der Panik! Aber mit defer diese wg.Done() ausgeführt werden, die am Ende, auch wenn Panik passiert. Auch, aufschieben, bevor close ist auch wichtig, da Ihr Ergebnis wirkt sich auch auf die Kommunikation.
So, hier ist der code modifiziert nach den Punkten, die ich oben erwähnt:
```
package main

import (
    "fmt"
    "sync"
)

func main() {
    ch := make(chan int)
    var wg sync.WaitGroup
    wg.Add(2)
    go Print(ch, &wg)
    go func() {

        defer func() {
            if r := recover(); r != nil {
                println("panic:" + r.(string))
            }
        }()

        defer func() {
            wg.Done()
        }()

        for i := 1; i <= 11; i++ {
            ch <- i

            if i == 7 {
                panic("ahaha")
            }
        }

        println("sender done")
        close(ch)
    }()

    wg.Wait()
}

func Print(ch <-chan int, wg *sync.WaitGroup) {
    defer func() {
        if r := recover(); r != nil {
            println("panic:" + r.(string))
        }
    }()

    defer wg.Done()

    for n := range ch {
        fmt.Println(n)
    }
    println("print done")
}
```
Hoffe es hilft 🙂
- Vielen Dank, dude!
- Ich Stimme überhaupt nicht mit der Don ' T entfernen Sie die wg von Print. Aber vielleicht ist mein Vorschlag nicht richtig verstanden, was ich beraten zu tun ist, etwas so : play.golang.org/p/lOopY0bYHT, Die Art und Weise, Ihre routine nicht wissen, dass das synchronisiert ist, das macht es einfacher. Als Faustregel gilt, dass es sei denn, die Synchronisation ist Teil des Algorithmus, der code sollte nie bewusst zu sein. Bedeutung, eine Methode, die etwas auf dem Bildschirm auszugeben sollte nie benötigen eine Synchronisation Bewusstsein.
- Es ist eine gute Idee, um von zu erholen Panik, aber in diesem Beispiel ist es zu übertreiben. Die einzige Sache, die Panik ist zu senden an einen geschlossenen Kanal, und Sie sind die, die ihn schließen. Don ' T fallen in die Falle zu kontrollieren alles zu jeder Zeit, das wird nur aufblasen Sie Ihren code mit unnötigen Kontrollen und machen es schwer zu Lesen.
- Ich sagte, ich Stimme mit Ihnen, weil Sie nur erwähnt, um entfernen Sie die wg von print, aber nie gesagt, es sollte Hinzugefügt werden, irgendwo anders. Und was ich will demo in meinem post erklärt, wie Fettschrift: lassen Sie niemals eine goroutine baumelt herum. Auch der Grund, warum ich hinzufügen, wieder für alle Funktionen ist, man weiß nie, Wann wird Sie in einigen Logik, dass die Ursachen der Panik, es kann keine Panik jetzt, aber es kann in der Zukunft.
- Am Ende der OP-Frage ist ein Beispiel, in dem er zeigen, wie er sich entfernen will, die wg aus der Funktion... ist das die Lösung war ich einverstanden (siehe mein Spielplatz Beispiel). Ich Stimme mit der baumelnden Routinen Warnung, aber offensichtlich ist dies eine Lehre, z.B. über Routinen. Und hinzufügen erholt überall, denn eines Tages könnte jemand code hinzufügen, verursachen Panik ist eine unnötige Vorsichtsmaßnahme, macht den coe nicht lesbar jetzt, und als solche ist wahrscheinlich, Fehler zu verursachen (die, ironischerweise, Auslöser der Panik, die Sie sind, schützen Sie sich aus).
InformationsquelleAutor nevets

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.