File writing with overlapped IO vs file writing in a separate thread

Question

Is there any advantage in using file writing with overlapped IO in Windows, vs just doing the file writing in a separate thread that I create?

[Edit - please note that I'm doing the file writes without system caching, ie I use the FILE_FLAG_NO_BUFFERING flag in CreateFile)

Answer 1

Possibly because overlapped I/O in windows will tell Windows to write out the file on it's own time in background, as opposed to spawning a whole new thread and engaging in a blocking operation?

Answer 2

I've just read this article:

http://msdn.microsoft.com/en-us/library/aa365683(VS.85).aspx

Answer 3

One advantage with overlapped I/O is that it lets a single thread (or more usually a pool of threads) to handle an arbitrary number of I/O requests concurrently. This might not be an advantage for an single-user, desktop application, but for a server application that can get requests for I/O from many different clients it can be a major win.

Answer 4

Since all writes are cached in the system cache by default, there is little advantage to doing overlapped I/O or creating a separate thread for writes at all. Most WriteFile calls are just memcpys at their core, which are lazily written to disk by the OS in an optimal fashion with other writes.

You can, of course, turn off buffered I/O via flags to CreateFile and then there are advantages to doing some sort of async I/O - but you probably didn't/shouldn't do that.

Edit

The OP has clarified they are in fact using unbuffered I/O. In that case the two suggested solutions are nearly identical; internally Windows uses a thread pool to service async I/O requests. But hypothetically Windows can be more efficient because their half is implemented in the kernel, has less context switches, etc.