这可能是不可能的，但我还是会问。我有一个多线程程序（服务器），它在专用于IP通信的线程上接收请求，然后将其传递给工作线程以进行工作，然后我必须向客户端发送回复并回复客户端并在发送时发送它实际上已经完成，尽可能少延迟。目前，我正在使用消费者/生产者模式，并将回复放在队列中，以便IP线程起飞并发送回我的客户端。然而，这无法保证何时会发生这种情况，因为IP线程可能不会很快安排，我不知道。这使得阻止此调用的客户端认为请求失败了，这显然不是重点。
由于我无法在客户端进行更改，我需要在我这边解决这个发送问题，我面临的问题是我不想开始共享我的IP对象（目前只有在1个线程上）与工作线程，因为事情变得过于复杂。我想知道是否有某种方法我可以使用线程同步机制来确保我的工作线程完成的那一刻，IP线程将执行我将回复发送回客户端？
手动/自动复位事件会为我做这个还是不能保证立即唤醒线程？
答案 0 :(得分：2)
没有同步机制会立即唤醒线程。当发信号通知线程正在等待的同步机制时，该线程被置于其优先级等级的就绪队列中。它可能会在计划之前在那里挨饿几秒钟（Windows确实有超过3-4秒间隔处理饥饿的机制）。
我认为对于带外，关键通信，您可以拥有一个更高优先级的线程，您可以将回复消息排入队列并将其唤醒（使用条件变量，MRE或任何其他同步机制）。如果该线程的优先级高于应用程序其余部分的线程，则将其唤醒将立即影响上下文切换。
答案 1 :(得分：2)
如果您需要立即发送 ，最好的办法是咬紧牙关并开始共享连接对象。当然，在访问它之前锁定它，并且一定要考虑如果发送缓冲区已经满了你会做什么（连接线程将需要处理发送第一次不适合的消息部分） ，或者工作线程将被阻止，直到客户端接受您发送的某些数据为止。如果您的客户一次只运行一个请求，这可能不会太困难;如果是这种情况，您可以在开始处理时将客户端对象的所有权简单地传递给工作线程，并在完成后将其传回。
另一种选择是使用实时线程。操作系统之间的细节会有所不同，但在大多数情况下，如果您的线程具有足够高的优先级，如果它已准备好运行，它将立即进行调度，并将抢占优先级较低的所有其他线程，直到完成为止。例如，在Linux上，可以使用SCHED_RR优先级类来完成。但是，在许多情况下，这会对性能产生负面影响;如果您的线程进入无限循环，则崩溃系统。它通常还需要管理权限才能使用这些调度类。
也就是说，如果调度花费的时间足以让客户端超时，那么加载时可能会遇到其他一些问题。你还应该准确地说出响应需要多快的数字 - 如果你想加快响应，你可以做的事情没有尽头，但是有一点不再重要（你呢？需要几十毫秒的响应？单位数ms？几百微秒？单位数微秒？）。