2

この問題の例は、ユーザーがリソースを作成してリソースを削除する場合です。操作を実行し、カウンター キャッシュをインクリメント (デクリメント) します。

テストでは、カウンター キャッシュが go ルーチンによって更新されていないという競合状態が発生することがあります。

編集: 混乱して申し訳ありませんが、明確にするために: カウンター キャッシュはメモリ内にありません。実際にはデータベース内のフィールドです。競合状態はメモリ内の変数に対するものではありません。実際には、ゴルーチンがデータベース自体に書き込むのが遅い可能性があります!

現在、操作後に 1 秒のスリープを使用して、カウンター キャッシュをテストする前にカウンター キャッシュが更新されていることを確認しています。go ルーチンが終了するのを待つために任意の 1 秒間スリープせずに go ルーチンをテストする別の方法はありますか?

乾杯

4

2 に答える 2

0

1 つの解決策は、値が変更されるとすぐに更新されるチャネルをカウンターが提供できるようにすることです。go では、結果を通信して同期するのが一般的です。たとえば、 次のCouterようになります。

type Counter struct {
   value int
   ValueChange chan int
}

func (c *Counter) Change(n int) {
    c.value += n
    c.ValueChange <- c.value
}

が呼び出されるたびChangeに、新しい値がチャネルを介して渡され、値を待っている人は誰でもブロックを解除して実行を継続するため、カウンターと同期します。このコードを使用ValueChangeすると、次のような変更をリッスンできます。

v := <-c.ValueChange

同時呼び出しc.Changeはもう問題ありません。

play に実行可能な例があります。

于 2013-09-23T14:50:41.737 に答える