1

週末にGoを使い始めたばかりですが、Goの特性を正しく使用したのか、それともこの「Goのような」ことをまったく行っていないのかわかりません。

コードは、と呼ばれるマップの要素を反復処理しnon_placed_alleles、これらの各要素をplaced_alleles、マップに格納されているのすべての要素と比較することになっています。non_placed_alleles比較にはかなりの費用がかかり、永遠にかかるため、要素ごとに1つのルーチンを使用しようとしています。

これが主な機能からのビットです：

runtime.GOMAXPROCS(8) // For 8 consecutive routines at once? got 10 CPUs
c := make(chan string)
for name, alleles := range non_placed_alleles {
    go get_best_places(name, alleles, &placed_alleles, c) 
    // pointer to placed_alleles as we only read, not write - should be safe?
}
for channel_item := range c {
    fmt.Println("This came back ", channel_item)
} 
// This also crashes with "all goroutines are sleeping", 
// but all results are printed

そして、これが呼び出された関数です：

func get_best_places(name string, alleles []string, placed_alleles *map[string] []string, c chan string) {
    var best_partner string
    // Iterate over all elements of placed_alleles, find best "partner"
    for other_key, other_value := range *placed_alleles {
        best_partner := compare_magic() // omitted because boring
    }
    c <- best_partner
}

これを「より良く」する方法はありますか？もっと早く？ポインタマジックとゴルーチンを正しく使用しましたか？

4

1 に答える 1

2

いくつかの観察：

  • おそらく、バッファリングされたチャネルを使用する必要があります

    c := make(chan string, someNumber) // someNumber >= goroutines cca

  • デッドロックは、誰も閉じていないチャネルのレンジングに起因します (これが range ステートメントの終了方法です)。Go で何かを調整するための機械は、タスクごとに異なります。この場合、おそらくsync.WaitGroupを使用する人もいます。WaitGroup の適切な使用に関するヒントについては、前のリンクの下にあるサンプル コードをよく確認してください。代替手段は、開始されたワーカーと終了したワーカーをカウントする何らかの/他の種類/方法です (WaitGroup がカプセル化しますが、私はそれをやり過ぎと見なす傾向があります)。

  • この場合、map にポインターを渡す必要はありません。Go のマップには、完全な参照セマンティクスがあります (これは、ボンネットの下にあるポインターにすぎません)。

于 2013-02-11T11:10:29.097 に答える