多线程：经典的生产者消费者算法

Question

关于生产者-消费者问题的经典算法，我不明白的事情（来自维基百科：）

semaphore mutex = 1
semaphore fillCount = 0
semaphore emptyCount = BUFFER_SIZE

procedure producer() {
    while (true) {
        item = produceItem()
        down(emptyCount)
            down(mutex)
                putItemIntoBuffer(item)
            up(mutex)
        up(fillCount)
    }
    up(fillCount) //the consumer may not finish before the producer.
}

procedure consumer() {
    while (true) {
        down(fillCount)
            down(mutex)
                item = removeItemFromBuffer()
            up(mutex)
        up(emptyCount)
        consumeItem(item)
    }
}

我注意到生产者和消费者在弄乱缓冲区之前都会锁定“互斥体”，然后再将其解锁。如果是这种情况，即在任何给定时刻只有一个线程正在访问缓冲区，我真的看不出上述算法与仅需要在缓冲区上放置一个保护互斥体的简单解决方案有什么不同：

semaphore mutex = 1

procedure producer() {
    while (true) {
        item = produceItem()
        flag = true
        while (flag) {
            down(mutex)
            if (bufferNotFull()) {
                putItemIntoBuffer(item)
                flag = false
            }
            up(mutex)
        }
    }
}


procedure consumer() {
    while (true) {
        flag = true
        while (flag) {
            down(mutex)
            if (bufferNotEmpty()) {
                item = removeItemFromBuffer()
                flag = false
            }
            up(mutex)
        }
        consumeItem(item)
    }
}

我唯一能做的就是认为需要使用“fillCount”和“emptyCount”信号量是调度。

也许第一个算法是为了确保在 5 个消费者正在等待空缓冲区（零“fillCount”）的状态下，可以确保当新的生产者出现时，它将超过其“down(emptyCount)”快速声明并快速获取“互斥体”。

（而在另一种解决方案中，消费者将不必要地获得“互斥体”，只是为了放弃它，直到新的生产者获得它并插入一个项目）。

我说得对吗？我错过了什么吗？

Answer 1

如果缓冲区中没有消息，消费者将降低互斥体，检查缓冲区，发现它是空的，增加互斥体，循环并立即重复该过程。简单来说，消费者和生产者陷入了占用 100% CPU 核心的繁忙循环中。这也不仅仅是一个理论问题。您可能会发现每次运行程序时计算机的风扇都会开始旋转。

Answer 2

生产者/消费者模式的漏洞概念是仅在满足特定条件时才访问共享资源（缓冲区）。并且不使用不必要的 CPU 周期以确保满足要求。

消费者：

• 如果没有什么可以消费（=>空缓冲区），请等待。

生产者：

• 如果缓冲区空间不足，请等待。

对于两者来说，值得注意的是：

• 等待！=旋转等待

Answer 3

发生的不仅仅是缓冲区的锁定。

第一个程序中的 fillCount 信号量用于在没有剩余内容可供消费时暂停消费者。如果没有它，您就需要不断地轮询缓冲区以查看是否有任何内容可以获取，这是相当浪费的。

同样，当缓冲区已满时，emptyCount 信号量会暂停生产者。

Answer 4

如果涉及多个消费者，就会出现饥饿问题。在后一个示例中，消费者在循环中检查项目。但当他再次尝试时，其他消费者可能会“偷走”他的物品。下次再一次，再一次。这可不太好。