意味

それぞれ「プロデューサー」と「コンシューマー」と呼ばれる 2 つのプロセスを考えます。プロデューサは周期的なプロセスであり、そのサイクルが完了するたびに情報の特定の部分が生成され、コンシューマはこれを処理する必要があります。コンシューマも循環的なプロセスであり、そのサイクルを通過するたびに、プロデューサによって生成された次の情報を処理できます。単純な例は、消費者の役割を果たすパンチカードによってパンチされるパンチカードの画像を「情報の一部」として生成する計算プロセスによって示されます。[1]

説明

プロデューサーはアイテムを作成してデータ構造に保存し、コンシューマーはその構造からアイテムを削除して処理します。

消費量が生産量より大きい場合、バッファ (データ構造) が空になり、消費者は消費するものが何もなくなります
消費量が生産量より少ない場合、バッファがいっぱいになり、生産者はそれ以上アイテムを追加できなくなります。これは 制限されたバッファ. と呼ばれる古典的な問題です。

問題の文脈化

バッファ内の電子メールを公開するプロデューサーと、バッファから電子メールを消費し、指定された電子メールの新しいアクセス パスワードを使用して電子メールが送信されたことを示すメッセージを表示するコンシューマがあるとします。

Goの実装

パッケージメイン 輸入 （ 「fmt」 "あなた" 「strconv」 「同期」 "チーム" ) 型バッファ構造体 { アイテム[]文字列 ミュー同期ミューテックス } func (buff *buffer) add(項目文字列) { buff.mu.Lock() buff.mu.Unlock() を延期する if len(buff.items) package main import ( "fmt" "os" "strconv" "sync" "time" ) type buffer struct { items []string mu sync.Mutex } func (buff *buffer) add(item string) { buff.mu.Lock() defer buff.mu.Unlock() if len(buff.items) 実装の説明

まず、
• buffer という構造体を作成します。これには、items という文字列の配列と、同時アクセスを管理するための mu というミューテックスのような制御メカニズムが含まれています。
関数は 2 つあります。1 つは add と呼ばれるもので、バッファー容量は 5 項目のみであるため、基本的に空き領域がある限りバッファーに項目を追加します。もう 1 つの get 呼び出しは、バッファー内に項目がある場合、最初の要素を返し、その要素をバッファーから削除します。
• Producer は基本的にループからインデックスを取得し、それを str という文字列に連結します。この文字列にはインデックスとダミーの電子メール ドメインが含まれ、バッファーに追加されます。遅延をシミュレートするために時間間隔が追加されました。
• Consumer は、少なくとも 1 つのアイテムがある場合、バッファーからアイテムをリクエストします。その後、コンシューマは、バッファ内に公開されたアイテムの新しいアクセス パスワードが記載された電子メールが送信されたことを通知するメッセージを画面に表示します。

コードリンク: https://github.com/jcelsocosta/race_condition/blob/main/Producerconsumer/buffer/Producerconsumer.go

参照

https://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD123.html#4.1。一般セマフォの一般的な使用法。

参考文献

https://www.cin.ufpe.br/~cagf/if677/2015-2/slides/08_Concorrencia (ホルヘ).pdf