Let’s assume my car’s light is broken. I have no idea about anything inside my car and can’t help myself. So I bring it to a garage and let somebody who knows how fix the light.
I arrive there but the mechanician tells me he has no time. There are other cars which need to be fixed first. He will text me when it’s done though.

That’s okay with me. These days you should consider yourself lucky when they even find time to talk to you. However, will I hang around there for I don’t know how many hours? God no, of course not! I can do plenty of other things than sitting in the garage: Go shopping, have dinner, work a few hours, meet somebody, etc.
If I would tell to anybody I’ve waited five hours in the garage for my lights he would tell me what crazy guy I am. There are obviously better ways to spend five hours than watching the garage’s pin up calendars.

As soon as we change into the software world though, it is considered normal by the majority to wait that long.

Of course there are ways to get a beep as well when things are ready for you but many developers I met prefer to put their program waiting in the garage instead of letting it doing something useful. Furthermore, when they mention how much they waited, they almost never hear what crazy thing they just did.

An operating system provides exactly the mechanism required to be able to start an operation and then do more useful things than waiting for its result. How many of us use them consistently?

On Windows for example there are the overlapped I/O operations. You pass a special structure which contains an event while calling your long during operation. If the system decides it should not execute it synchronously, the method returns immediately and you are free doing other things while your request gets executed by the operating system. After running out of stuff you could compute and prepare, you actively wait for your first call to end and will be woken up when the system completed your request and presents you the results from the first call.

On Linux we have similar possibilities of course. Asynchronous operations like “aio_read()” or “aio_write()” may be called and the caller has then the possibility to do other things like allocating new buffers, compute the result from the last read operation, etc. When the new result is needed, “aio_suspend()” can be called to await the I/O operation’s completion. Note for my PnProgging friends: In case you are wondering, I/O Multiplexing (select/poll) is blocking and thus not the same as asynchronous operations.

Not really hard, isn’t it? Just I almost never see it in other’s code. They prefer letting their software wait instead of doing something more useful. Nobody would ever wait for hours in a garage because its obvious to anybody how inefficient that would be. In our software world though, it is not considered that silly anymore. Most of the I/O operations I saw in projects were done synchronously. As if our software was fast and we would have enough time anyway.

When I see such code and investigate why it has been solved that way, the developers responsible I talk to start to flame about how complicate asynchronous operations are. That’s like saying you cannot go shopping after leaving your car in the garage because it requires you to think what you will do when you finished shopping.

The sad thing is, this is not just the case with low level I/O operations. Asynchronous behavior is another great thing which doesn’t get adopted because there are too many guys out there who don’t understand it and prefer their old, simple and inefficient solutions.

You can find this kind of thinking almost everywhere. I experienced it many times. For example when I provided asynchronous execution for long during operations in my classes. People started to claim that it’s too complex and were happy that they could go on abusing their UI threads. Of course they have a point here, asynchronous things require further synchronization and thus makes the code longer and harder to read. But for me it sounds like when somebody tells me we shouldn’t use C++ templates because they are too hard. Or we shouldn’t target parallelization because of synchronization issues. Or recursion should be avoided because it’s hard to understand.

But guess what? Software is hard!