Used judiciously, asynchronous I/O (AIO) can provide a significant speed benefit, says David Chisnall. Perhaps enough to help your program overcome the fact that modern processors can really zoom, while hard drives still drag.
POSIX Asynchronous I/O
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Wow. More useless misleading crap from informit.
aio won’t buy you anything in the cases outlined in the example because stdio does buffered read ahead.
almost anyplace where aio will buy you anything, have an i/o worker thread will buy you the same performace, but with easier to understand code.
Thanks for pointing out another book not to buy.
I thought the article was a decent introduction on how to set up and use AIO. Sure, the examples could’ve been done using stdio, but the author said as much. The benefits of AIO are hard to illustrate usefully in a short example, so its not surprising that the examples aren’t that useful.
As for I/O worker threads, I disagree on both counts. On most platforms, I/O worker threads won’t scale nearly as well as AIO and a notification mechanism like epoll or kqueue. Moreover, lots of people find an notification-driven application much simpler to understand than a threaded one.
“Wow. More useless misleading crap from informit.”
With everyone always pointing out how useless and misleading informit articles are it kind of makes you wonder why they are continuously being posted as news.
>With everyone
No, this is not “everyone”. It’s just 1 to 5 people, and only sometimes. Obviously, there are 274,995 more people who find it useful in a single day.
This article is just fine, like most hosted on InformIT are. Their articles will be continued to be posted here.
“No, this is not “everyone”.”
My apologies, I wasn’t clear enough. I meant “everyone who knows what they are talking about”.
Hahahah
touche!
Stdio won’t cut it because you may end up being blocked in spite of the buffering.
Comparing it to using select/poll, or with using your own i/o thread(s) as you mentionned rightly.
The article is not total crap as it provides good starting points for using aio.
The article is fine and AIO is fine. The programming model behind POSIX AIO is a perfectly valid one, and indeed one that compares very positively to a threaded model for doing non-blocking IO. The biggest problem with POSIX AIO is not the API, but how poorly supported it is in most mainstream systems. Solaris is the only OS I know of with a throughly complete and high-performance implementation of general non-blocking operations. It not only ties POSIX AIO into the central event completion framework, but network operations, timers, etc.
Edited 2006-09-25 04:49
I’m not arguing that AIO isn’t a valid i/o approach.
I’m only pointing out that if the only information one had was the information in this article, one would end up using AIO inappropriately.
Despite Eugenia’s assertion, most of the articles on Informit that are posted here are crap. At best they are teaser ads for the books and shouldn’t be posted as if they were hard information. At worst, and worst is pretty common, they are badly misleading.
This article falls in the middle some place. It is definitely a teaser ad, but it is mildly misleading, because it motivates using AIO with an inappropriate example.
And no, Eugenia, it isn’t “obvious” that x thousand people find the articles useful. Even if you’ve got the viewing stats on the URL, at most you can say that X thousand people looked at it.
This is PURE UNIX baby 🙂
The use of threads will slow things down significantly. I work in a Computer Vision project. For testing purposes we have very big avis of raw frames (RGB/8bit) under Linux that we load in order to see the performance of our algorithms. We also do the same with the use of an AXIS 213 PTZ camera. I know what to do with the processor cycles waiting for I/O
1. In the camera case I can decompress the JPEGs to convert them to RGB images for background subtraction
2. In the AVI case I can start processing the images before I/O is ready.
Multithreading would be an overkill.
The use of threads will slow things down significantly.
Not in your CV application. You have a pure consumer producer problem so the synchronization overhead is the same for either aio or threading. It’s really a matter of taste how you want to program it in this case.