Picture two members of the Microsoft .NET Framework development team meeting in the break room.

Programmer 1: "Can you imagine an application developer trying to do an asynchronous write in a C# program?"

Programmer 2: "Ha! I wonder if he'll just code it up and assume that it's asynchronous, or if he'll notice that it blocks and spend hours trying to figure out why."

Programmer 1: "Either way it'd be a hoot to watch, wouldn't it?"

Programmer 2: "Yeah. I love messing with peoples' heads."

Okay, so perhaps the .NET Framework developers didn't purposely make the asynchronous file operations work synchronously. It's even possible that whoever wrote the asynchronous file I/O support didn't know that it sometimes doesn't work as expected. But that shortcoming had to be revealed during testing, right?

Apparently not, as the .NET Framework SDK documentation makes almost no mention of the possibility that an asynchronous file operation will block and complete synchronously. In addition, most asynchronous I/O samples in the SDK and on other Web sites show "asynchronous" operations that don't actually execute in the background.

In this article, I'll show you how the asynchronous file I/O routines are supposed to work, demonstrate that they often don't work as expected, explain why, and show you how to guarantee that your asynchronous file operations occur in the background without blocking the main execution thread.

A Refresher

To a processor capable of several billion operations per second, an I/O device that requires milliseconds for positioning and transfers data at a couple hundred megabits per second is slow, even glacial. Whenever your application writes data to or reads data from a disk or network file, the processor spends most of its time waiting for the I/O channel or servicing other tasks. In either case, your program's execution is blocked, waiting for the file operation to complete. Even with fast hard drives that can write 10MB or more per second, that's a full second that your application is unresponsive. Try blocking your GUI application for a full second, and see how quickly your users complain about a clunky interface.

Another situation in which slow file operations are annoying is when you have to read from or write to multiple files. Imagine having to read two different large files when your application starts. Each file takes 15 seconds to load, which means that it takes 30 seconds for your application to load. It probably wouldn't surprise you to learn that you could load both files in a total of about 15 seconds if you could tell the computer to do two things at once. While it's waiting on the I/O channel for one of the files, it can be gathering data from the other file.

Operations that occur in the order that they're specified are said to occur synchronously. Most of the time, we want our programs to operate synchronously, because the program's logic depends on it. It would be unfortunate, for example, if the computer tried to use the result of a calculation before the result was computed.

Sometimes, though, we don't really care about the order of some intermediate steps, just so long as all of the steps are completed before we have to use any of the results. For example, think of the instructions to bake cookies:

• Gather the ingredients
• Preheat the oven to 450 degrees
• Lightly grease a cookie tray
• Mix the ingredients in a bowl
• Put the cookie dough on the tray
• Place tray in oven and cook until golden brown

It's pretty obvious here that it doesn't matter in what order the first three operations happen, or if they all happen concurrently. You just have to make sure that you gather the ingredients before you try to mix them, that the cookie tray is greased and the ingredients are mixed before you put the dough on it, and that the oven is preheated before you pop the tray in. If you have a helper, you can save time by having him preheat the oven and grease the cookie tray while you're gathering and mixing the ingredients.

What you have here, and in many computer programs, is small sets of operations that can happen in any order, and synchronization points where you ensure that the previous operations are complete. If you add the synchronization points to the cookie instructions, you can draw a flow chart that illustrates the tasks that can be performed concurrently.

Wouldn't it be nice if you could do the same thing with your file I/O? Just think if you could load seldom-used data in the background while the user is navigating through menus. That would be a much nicer user experience than staring at a splash screen while the data buffers are initialized.

Next: ' Reading and Writing Asynchronously ' >>

Discuss Making Asynchronous File I/O Work in .NET: A Survival Guide   >>> Be the FIRST to comment on this article!

>>> More Using VS Articles          >>> More By Jim Mischel