2

On windows, when you do I/O, you can do it async using the OVERLAPPED option. Is there any difference between doing that vs performing the I/O synchronously on another thread? If so, which is better? Does the OS just spawn a separate thread in async case, or does it just queue it on the driver thread and send signal instead of block wait?

Thanks!

user1181950
  • 779
  • 1
  • 9
  • 21
  • The operating system almost certainly doesn't spawn new threads just to service your overlapped I/O request. Look up [I/O completion ports](http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198.aspx), which actually require that you provide your own threads to pull completion notifications out of the I/O completion port. Exactly how Windows does it is an implementation detail, but by virtue of being an operating system it can pull some tricks besides spawning threads. – In silico Sep 04 '14 at 02:10
  • 1
    I've had mixed results with async i/o - especially with the WriteFile call. Certain WriteFile operations invoked with the OVERLAPPED flag would actually block instead of returning immediately. As much as I wanted to make the overlapped i/o stuff work, it just added complexity to the code since I still had to poll/wait for the overlapped operation to be completed... In the end, the "spawn a thread" approach was actually simpler to implement and didn't cause any ill effects. YMMV. Prototype and measure to confirm the expected benefits - the results may surprise you. – selbie Sep 04 '14 at 04:24

2 Answers2

2

Windows I/O is inherently asynchronous, so performing an async operation in .NET for example should not use a thread, once the operation completes some existing threads are briefly borrowed to notify of the operation's completion, but no threads are created.

That's quite different from running a synchronous operation on another thread. It uses up a thread which makes the program much less scalleable. In .NET a thread has a default local storage of 1MB so having thousands of threads running will consume gigabytes of memory. Then you also have the additional cost of switching between threads, which is usually small but can add up if you have a lot of threads.

NeddySpaghetti
  • 13,187
  • 5
  • 32
  • 61
  • 1
    Note that, by default, .NET’s Async methods on `FileStream` use a thread. You can specify `isAsync: true` in its constructor to get a `FileStream` that uses overlapped IO instead, but it seems that in the most common use scenarios this performs worse than the default threaded IO. So, by default, on .NET, there is a thread in userspace. Now, since it uses the `ThreadPool`, the cost of creating a thread is amortized and stack size won’t be an issue becauseof work queues and automatic pool size tuning generally avoids there being thousands of threads. – binki Jul 10 '18 at 18:57
0

According to MSDN dev center, "Asynchronous I/O is also referred to as overlapped I/O" furthermore it goes on to say that async io is handled by the kernel, in effect another thread. I dont know about you, but If I dont have to write something, I dont...It's my lazy programmer rule #1.

Steve
  • 502
  • 3
  • 12
  • 1
    well considering I have a thread pool for other purposes and synchronous IO is much easier to code up than OVERLAPPED IO, I can just throw it on a thread on my pool. But was wondering if there is any benefit to using OVERLAPPED vs just throwing onto another thread... – user1181950 Sep 04 '14 at 02:02
  • 2
    This question answered http://stackoverflow.com/questions/3050621/file-writing-with-overlapped-io-vs-file-writing-in-a-separate-thread says there isnt much speed difference, however a person does states using async in a thread pool your app can handled an arbitrary amount of IO calls, for instance in a server. – Steve Sep 04 '14 at 02:13