정의

우리는 각각 "생산자"와 "소비자"라는 두 가지 프로세스를 고려합니다. 생산자는 주기적인 프로세스이며, 주기를 거칠 때마다 소비자가 처리해야 하는 정보의 특정 부분을 생성합니다. 소비자 역시 주기적인 프로세스이며, 주기를 거칠 때마다 생산자가 생성한 대로 다음 정보를 처리할 수 있습니다. 간단한 예는 소비자 역할을 하는 천공 카드에 의해 천공될 천공 카드의 "정보 부분" 이미지를 생성하는 계산 프로세스에 의해 제공됩니다.[1]

설명

생산자는 항목을 생성하여 데이터 구조에 저장하고, 소비자는 해당 구조에서 항목을 제거하고 처리합니다.

소비가 생산보다 크면 버퍼(데이터 구조)가 비워지고 소비자는 소비할 것이 없습니다.
소비가 생산보다 적으면 버퍼가 채워지고 생산자는 더 이상 아이템을 추가할 수 없습니다. 이는 제한된 버퍼라고 하는 고전적인 문제입니다.

문제의 상황화

버퍼에 이메일을 게시하는 생산자와 버퍼에서 이메일을 소비하고 제공된 이메일에 대한 새 액세스 비밀번호가 포함된 이메일이 전송되었다는 메시지를 표시하는 소비자가 있다고 가정합니다.

구현 이동

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) 




  
  
  구현 설명

• 먼저, 항목이라는 문자열 배열과 동시 액세스를 관리하기 위한 뮤텍스와 유사한 제어 메커니즘을 포함하는 버퍼라는 구조를 만듭니다.
• 두 가지 기능이 있습니다. 하나는 add라는 기능으로, 버퍼 용량은 단 5개 항목이므로 기본적으로 사용 가능한 공간이 있는 한 버퍼에 항목을 추가합니다. 또 다른 get 호출은 버퍼에 항목이 있는 경우 첫 번째 요소를 반환하고 버퍼에서 해당 요소를 제거합니다.
• Producer는 기본적으로 루프에서 인덱스를 가져와 인덱스와 더미 이메일 도메인을 포함하는 str라는 문자열로 연결하고 이를 버퍼에 추가합니다. 지연을 시뮬레이션하기 위해 시간 간격이 추가되었습니다.
• 소비자는 항목이 하나 이상 있는 경우 버퍼에서 항목을 요청합니다. 그런 다음 소비자는 버퍼에 게시된 항목에 대한 새 액세스 비밀번호가 포함된 이메일이 전송되었음을 알리는 메시지를 화면에 표시합니다.

코드 링크: https://github.com/jcelsocosta/race_condition/blob/main/producerconsumer/buffer/producerconsumer.go

참조

1. https://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD123.html#4.1. 일반 세마포어의 일반적인 용도.

서지

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