WaitForSingleObject () vs RegisterWaitForSingleObject ()?

Question

What is the advantage / disadvantage of using RegisterWaitForSingleObject() instead of WaitForSingleObject() ?

The reason I know:

• RegisterWaitForSingleObject() uses a thread pool already available in the OS
• In the case of using WaitForSingleObject() native thread should be a poll for the event.

The only difference is polling versus auto event? or is there a significant performance advantage in between?

Answer 1

This is pretty straight forward, WaitForSingleObject () blocks the thread. It consumes a megabyte of virtual memory and does nothing useful with it while it is locked. He will not wake up and begin to do useful things until the handle is signaled.

RegisterWaitForSingleObject () does not block the stream. A thread can continue to do useful work. When the handle is signaled, Windows captures the thread pool thread to run the code that you specified as the callback. The same code that you programmed after calling WFSO. There is still a thread associated with getting this callback to start, the wait thread, but it can handle many RWFSO requests.

Thus, the big advantage is that your program can use far fewer threads when processing many service requests. The disadvantage is that the completion code may take a little longer. And it’s harder to program correctly, as this code runs on a different thread. Also note that you do not need RWFSO if you are already using overlapping I / O.

Answer 2

They serve two different code models. In the case of RegisterWaitForSingleObject you will receive an asynchronous notification callback in a random thread from the thread pool managed by the operating system. If you can structure your code like this, it can be more efficient. WaitForSingleObject , on the other hand, is a synchronous blocking of a wait call (thus "occupying") the calling thread. In most cases, this code is easier to write and is likely to be less error prone in various dead zone and race conditions.