死锁不是你应该检查的唯一东西。死锁总是很快被检测到 - 你的应用停止。丢失或重复的消息更加危险和隐晦 - 与du发生时相比,duped消息可能会导致应用程序崩溃的时间晚得多,并且很可能是在与dup发生的位置不同的模块/线程/块中。这样的错误是绝对的噩梦。
测试队列类时,我创建了一个带有内部随机数组[256]成员和校验和的'Message'类。我最初创建了10000条这些消息,'totalChecksum'它们各自的校验和,并将它们的指针推送到'池'队列中。多个生产者(我通常使用32),从池队列中弹出*消息实例,并将它们推送到另一个'通信'队列中。多个使用者(我通常使用16)pop *来自通信队列的消息实例,并将它们推回到缓冲池队列中。
热身房间5分钟后,一个简单的GUI窗体计时器通过设置一个挥发性布尔值来暂停生产者,该布尔值告诉生产者等待manualResetEvent。休眠(500)后,所有10000条消息应该回到池队列中,并且GUI检查池的队列计数是10000,在循环中弹出10000条消息,总计检查它们,推回来,最后与最初的总检查项进行比较。如果通过,则重置布尔值并发出MRE信号,以使生产者再次运行。
我一再运行这个测试过夜。如果有任何失败,该队列不适合用途。