golang でミューテックスがチャネルより遅いのはなぜですか?

なぜ golang ではミューテックスがチャネルよりも遅いのでしょうか?これは一般的な問題であり、多くの開発者がこの問題の原因を調査しています。ミューテックスとチャネルは、golang で一般的に使用される同期メカニズムであり、同時プログラミングにおいて重要な役割を果たします。ただし、ミューテックスのパフォーマンスがチャネルよりも悪い場合があります。これはなぜでしょうか? PHP エディターの Youzi が、この記事で読者が同時プログラミングにおけるパフォーマンスの違いをよりよく理解できるように、この質問に答えます。

質問内容

Webサイトを巡回してステータスを返すプログラムを作成しています。

私はこのプログラムを別の方法で書きました。 1 つ目は、ミューテックスを使用してマップへの同時書き込みを防止し、データ競合を取り除くことができます。次に、同じ目的でチャネルを使用して実装しました。しかし、ベンチマークを行ったところ、チャネルを使用して実装した方が、ミューテックスを実装するよりもはるかに高速であることがわかりました。なぜこれが起こるのか知りたいです?ミューテックスのパフォーマンスが低いのはなぜですか?ミューテックスで何か間違ったことをしているのでしょうか?

ベンチマーク結果:

＃＃＃コード＃＃＃ リーリー

テストコード

package concurrency

import "sync"

type websitechecker func(string) bool
type result struct {
    string
    bool
}

func checkwebsites(wc websitechecker, urls []string) map[string]bool {
    results := make(map[string]bool)
    var wg sync.waitgroup
    var mu sync.mutex
    for _, url := range urls {
        wg.add(1)
        go func(u string) {
            defer wg.done()
            mu.lock()
            results[u] = wc(u)
            mu.unlock()
        }(url)
    }
    wg.wait()
    return results
}

func checkwebsiteschannel(wc websitechecker, urls []string) map[string]bool {
    results := make(map[string]bool)
    resultchannel := make(chan result)
    for _, url := range urls {
        go func(u string) {
            resultchannel <- result{u, wc(u)}
        }(url)
    }
    for i := 0; i < len(urls); i++ {
        r := <-resultchannel
        results[r.string] = r.bool
    }
    return results
}

回避策

相互排他的なバージョンのコードを使用すると、

results

マッピングだけでなく wc も保護できるように思えます。 (呼び出しはロックを取得した後にのみ実行できるため、呼び出しを効果的にシリアル化できます)。 chan への送信は、右側の準備ができた場合にのみチャネルをロックするため、wc への呼び出しは同時に発生する可能性があります。コードが のようになっているかどうかを確認してください リーリー ミューテックスを使用するとパフォーマンスが向上します。

以上がgolang でミューテックスがチャネルより遅いのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。