根据crossbeam::Parker文档：park方法阻塞当前线程，除非或直到令牌可用，此时它会自动消耗令牌。它也可能不消耗令牌而虚假返回。你应该如何检测到一个虚假的唤醒发生了？在内部，帕克似乎使用了一个原子来跟踪令牌是否已经被消耗，但是除了park和park_timeout方法之外，似乎没有一种方法来查询它的状态。
crossbeam::Parker
park
park_timeout
alen0pnh1#
这个问题已经在相关的GitHub上被确认为一个问题，并且已经提交了一个pull request来修复它。一旦合并并发布了pull请求，我将用修复问题的版本更新这个答案，并将这个问题标记为已解决。更新：至少从横梁0.8.2开始，此问题已得到解决
mznpcxlj2#
你应该以其他方式处理它。例如，如果你手动实现一个mpsc通道，你的recv函数可能看起来像这样：
recv
loop { if let Some(message) = self.try_recv() { return message; } park(); }
在这种情况下，如果一个伪唤醒发生，循环将尝试再次获得它正在等待的东西，但由于这是一个伪唤醒，东西是不可用的，循环只是再次进入睡眠。一旦send实际发生，发送方将unpark接收方，在这一点上try_recv将成功。这种通道实现的一个例子是可用的here（source），尽管它使用CondVar而不是驻留线程，但它的思想是相同的。
send
try_recv
CondVar
2条答案
按热度按时间alen0pnh1#
这个问题已经在相关的GitHub上被确认为一个问题，并且已经提交了一个pull request来修复它。一旦合并并发布了pull请求，我将用修复问题的版本更新这个答案，并将这个问题标记为已解决。
更新：至少从横梁0.8.2开始，此问题已得到解决
mznpcxlj2#
你应该以其他方式处理它。例如，如果你手动实现一个mpsc通道，你的
recv函数可能看起来像这样：在这种情况下，如果一个伪唤醒发生，循环将尝试再次获得它正在等待的东西，但由于这是一个伪唤醒，东西是不可用的，循环只是再次进入睡眠。一旦
send实际发生，发送方将unpark接收方，在这一点上try_recv将成功。这种通道实现的一个例子是可用的here（source），尽管它使用
CondVar而不是驻留线程，但它的思想是相同的。