调度程序在返回之前是否可以中断线程？

我有两个线程作为生产者，消费者。在生产者线程我有下面的代码：调度程序在返回之前是否可以中断线程？

{ 
    mediaQueue->PushEvent(boost::bind(/* params are not important */)); 

    return 0; 
}

mediaQueue是一个消息队列，并在PushEvent（）调用线程将被告知有要处理的作业。消费者线程只执行用绑定创建的仿函数。

对于我来说，生产者线程在消费者线程执行仿函数之前返回是非常重要的。

所以这个问题：生产者是否有可能在推动事件之后但在它返回之前被中断？

我的研究到目前为止我认为这是可能的，我应该实现锁定，但你对此有何看法？

调度程序可以随时中断您的线程。它不（必然）知道或关心你的线程在时间到了的时候正在做什么。如果有可能的竞争条件，是的，你必须花时间和精力来实现正确的锁定。

就你而言，这很简单。只需等待从PushEvent函数返回的被调用函数中设置的对象。

2012-05-04 08:48:44

是的 - 这是奇怪的要求。正如你所说，在消费者到达代码主体之前使用同步对象强制生产者返回，肯定会起作用，但当消费者醒来时很可能导致近乎毫无意义的上下文更改队列，然后在明确的同步等待上:(再次，最好，（唯一的）解决方案来解决不合理的请求，所以+1。 –

@MartinJames：尽管如此，没有同步的代码似乎可以正常工作，那么线程当前正在按照“正确”的顺序执行，所以同步将会很便宜，因为同步对象将在需要在另一个线程中获取之前被释放。 UB的时间变化时，对于时机变化时双重上下文切换的机会是一个很大的交易:-) –

@Steve Jessop是的，那正是我的观点。代码是这样工作的，但是我确信一旦它开始生产就会引发问题:) –

是的，这是可能的。一个线程可以随时取消预定。

听起来好像有什么问题，但如果执行语句return 0;时很重要。是否真的要在函数之前执行返回，还是生产者线程要做的其他事情？

2012-05-04 08:49:58

是的，这是一个设计问题，但不幸的是我无法控制。它的工作原理如下 1.客户端发送请求并等待接受的同步确认 2.服务器接受呼叫（通过回调）并返回0或1 3.客户端等待关于结果的异步响应。这里的问题是，如果第二个线程在返回之前开始，我可能会发送一个尚未确认为已接受的作业的结果。 –

听起来像是消费者线程需要等待的接受的结构，而不是您显示的代码中的回报。 –

@tsurko - 不明白。为什么在将作业排队到第二个线程之前，不要发送accept？ –

回答