1

As an excercise I want to implement a solution to the producer-consumer problem. Let's say I'll have an array int[] buffer and two methods Produce() and Consume() that will simulate the producer and customer, respectively, and one "Execute" method to call both method asynchronously.

It's probably to test whether the implementation will not result in a deadlock, just make Produce and Consume repeat for a large number of time (like 1 million), make Execute wait for these two methods to finish, and then (in my unit test) just make sure the call returns after certain time (maybe 1 minute). But how to test whether there is no race condition or data corruption in the implementation?

4

1 回答 1

1

死锁不是您应该检查的唯一内容。死锁总是很快被检测到 - 你的应用程序停止。丢失或重复的消息更加危险和阴险——一条被复制的消息可能导致应用程序崩溃的时间比发生重复的时间要晚得多,而且很可能是在与发生重复的地方不同的模块/线程/块中。这样的错误绝对是一场噩梦。

在测试队列类时,我创建了一个带有内部随机数组 [256] 成员和校验和的“消息”类。我最初创建了 10000 条这些消息,“totalChecksum”它们各自的校验和,并将指向它们的指针推送到“池”队列中。多个生产者(我通常使用 32 个)从池队列中弹出 *Message 实例并将它们推送到另一个“通信”队列。多个消费者,(我通常使用 16 个)从通信队列中弹出 *Message 实例并将它们推回池队列。

在房间预热 5 分钟后,一个简单的 GUI 表单计时器通过设置一个告诉生产者等待 manualResetEvent 的 volatile 布尔值来停止生产者。Sleep(500) 之后,所有 10000 条消息都应该返回池队列中,并且 GUI 检查池队列计数是否为 10000,循环弹出 10000 条消息,totalChecksumming 它们,推回并最终与初始 totalChecksum 进行比较。如果通过,布尔值被重置,MRE 发出信号让生产者再次运行。

我一夜之间反复运行这个测试。如果有任何故障,则队列不适合目的。

于 2013-02-13T08:02:48.093 回答