Notes for writing iocp (mirosoft)

Tip 1: Use Winsock2 iocp-capable functions, such as wsasend and wsarecv, over Win32 file I/O functions, such as writefile and readfile.

Tip 1: Try to use wsasend and wsarecv for data sending and receiving

Socket handles from Microsoft-based protocol providers are ifs handles so you can use Win32 file I/O CILS with the handle. however, the interactions between the provider and file system involve kernel/user mode transition, thread context switches, and parameter values als that result in a significant performance penalty. you shoshould use only Winsock2 iocp-capable functions with iocp.

The additional parameter parameters als and mode transitions in readfile and writefile only occur if the provider does not have xp1_ifs_handles bit set in dwserviceflags1 of its wsaprotocol_info structure.

Note: These providers have an unavoidable additional mode transition, even in the case of wsasend and wsarecv, although readfile and writefile will have more of them.

Tip 2: choose the number of the concurrent worker threads allowed and the total number of the worker threads to spawn.

Tip 2: determine the appropriate number of worker threads

The number of worker threads and the number of concurrent threads that the iocp uses are not the same thing. you can decide to have a maximum of 2 Concurrent threads used by the iocp and a pool of 10 worker threads. you have a pool of worker threads greater than or equal to the number of concurrent threads used by the iocp so that a worker thread handling a dequeued completion packet can call one of the Win32 "wait" functions without delaying the handling of other queued I/O packets.

If there are completion packets waiting to be dequeued, the system will wake up another worker thread. eventually, the first thread satisfies it's wait and it can be run again. when this happens, the number of the threads that can be run is higher than the concurrency allowed on the iocp (for example, numberofconcurrentthreads ). however, when next worker thread CILS getqueuecompletionstatus and enters Wait Status, the system does not wake it up. in other words, the system tries to keep your requested number of concurrent worker threads.

Typically, you only need one concurrent worker thread per CPU for iocp. To do this, enter 0 for numberofconcurrentthreads in the createiocompletionport call when you first create the iocp.

Tip 3: associate a posted I/O operation with a dequeued completion packet.

Tip 3: Perform Io operations based on the completed package.

Getqueuedcompletionstatus returns a completion key and an overlapped structure for the I/O when dequeuing a completion packet. you shoshould use these two structures to return per handle and per I/O operation information, respectively. you can use your socket handle as the completion key when you register the socket with the iocp to provide per handle information. to provide per I/O operation "extend" the overlapped structure to contain your application-specific I/O-state information. also, make sure you provide a unique overlapped structure for each overlapped I/O. when an I/O completes, the same pointer to the overlapped I/O structure is returned.

Tip 4: I/O completion packet queuing behavior.

Tip 4: complete the exception handling of the package.

The order in which I/O completion packets are queued in the iocp is not necessarily the same order the Winsock2 I/O callwere made. additionally, if a Winsock2 I/O call returns success or io_pending, it is guaranteed that a completion packet will be queued to the iocp when the I/O completes, regardless of whether the socket handle is closed. after you close a socket handle, future callto wsasend, wsasendto, wsarecv, or wsarecvfrom will fail with a return code other than success or io_pending, which will not generate a completion packet. the status of the completion packet retrieved by getqueuedcompletionstatus for I/O previusly posted cocould indicate a failure in this case.

If you delete the iocp itself, no more I/O can be posted to the iocp because the iocp handle itself is invalid. however, the system's underlying iocp kernel structures do not go away until all successfully posted I/OS are completed.

Tip 5: iocp cleanup.

Tip 5: Release the port.

The most important thing to remember when invention Ming ICOP cleanup is the same when using overlapped I/O: do not free an overlapped structure if the I/O for it has not yet completed. the hasoverlappediocompleted macro allows you to detect if an I/O has completed from its overlapped structure.

There are typically two scenarios for shutting down a server. in the first scenario, you do not care about the completion status of outstanding I/OS and you just want to shut down as fast as you can. in the second scenario, you want to shut down the server, but you do need to know the completion status of each outstanding I/O.

In the first scenario, you can call postqueuecompletionstatus (n times, where N is the number of worker threads) to post a special completion packet that informs the worker thread to exit immediately, close all socket handles and their associated overlapped structures, and then close the completion port. again, make sure you use hasoverlappediocompleted to check the completion status of an overlapped structure before you free it. if a socket is closed, all outstanding I/O on the socket eventually complete quickly.

In the second scenario, you can delay exiting worker threads so that all completion packets can be properly dequeued. you can start by closing all socket handles and the iocp. however, you need to maintain a count of the number of outstanding I/OS so that your worker thread can know when it is safe to exit the thread. the performance penalty of having a global I/o counter protected with a critical section for an iocp server is not as bad as might be expected because the active worker thread does not switch out if there are more completion packets waiting in the queue.