.Net超时：WaitForSingleObject与Timer

Question

我正在异步操作（一系列网络IO）上实现超时，我不确定哪个'更好'（从分配/性能）角度来看：创建EventWaitHandle并使用RegisterWaitForSingleObject，或者只是创建一个Timer并使用它的Tick。

在我的特定情况下，EventWaitHandle是惰性创建的，但显然它必须实例化才能使用WaitForSingleObject。所以这真是一个关于WaitHandle + WaitForSingleObject与Timer的资源成本的问题。这两种方法都很容易实现。

我已经在不同的时间实现了这两个，所以我了解地形，我只是不确定哪种方法“更好”。

Answer 1

微软的Morgan Skinner seems to prefer RegisterWaitForSingleObject。

就分配而言，反射器显示RegisterWaitForSingleObject创建RegisteredWaitHandle的实例，而计时器创建内部TimerBase，以及名为{{1的类}}。可以继续比较这些类的大小等等，但它们似乎有更多的依赖关系，特别是非托管的（都使用底层的win32函数） - 所以我真的不能给出一个直接的答案。

关于传递给_TimerCallback的等待句柄，请记住，您可以分配一个Maunal / AutoResetEvent并将其传递给所有调用（因为您指望超时，所以您永远不会发出信号无论如何）。

就性能而言，我也不确定。 ThreadPool将为通过RegisterWaitForSingleObject注册的每63个动作使用一个特殊的等待线程。相反，计时器将使用底层的win32计时器。两者最终都会使用ThreadPool工作线程进行实际执行。哪种情况更好？打败我..所以我会和Skinner一起去看这个:)。

另见：

• Multithreading: registered waits
• Multithreading: coding the register wait pattern

Answer 2

没有比这更好的了。计时器用于定期“戳”你的线程做某事。 WaitForSingleObject等待句柄。超时是存在的，因此您可以使用它来决定停止等待而不是陷入死锁。如果使用超时，则不需要使用计时器来将waitfors单个对象从锁定中断出来。

两者的资源成本可以忽略不计。我不能说你应该使用哪种方法，因为它高度依赖于你所拥有的代码情况。