User: Password:
|
|
Subscribe / Log in / New account

Asynchronous buffered file I/O

Asynchronous buffered file I/O

Posted Jan 9, 2007 8:11 UTC (Tue) by ldo (guest, #40946)
Parent article: Asynchronous buffered file I/O

Some operating systems from nearly thirty years ago were already providing this feature, in a very simple way: decouple I/O from process scheduling. This way, there is no distinction between "synchronous" and "asynchronous" I/O in the kernel at all--as far as the kernel is concerned, all I/O operations are asynchronous.

Instead, the distinction is implemented entirely in userspace. The synchronous versions of the I/O calls actually make two kernel calls: "request I/O operation" followed by "wait for completion". No need for special paths through the kernel for handling synchronous versus asynchronous kinds of I/O operations.


(Log in to post comments)

Asynchronous buffered file I/O

Posted Jan 9, 2007 16:53 UTC (Tue) by nix (subscriber, #2304) [Link]

The problem is that the vast majority of all I/O ops are synchronous, so needing multiple syscalls for them is unnecessary overhead. (You might think `who cares, the I/O will dominate', but it may not with e.g. fast network cards).

Plus, synchronous I/O was there first (I suspect this is the *real* reason why it gets syscalls of its own).

Asynchronous buffered file I/O

Posted Jan 10, 2007 5:57 UTC (Wed) by ldo (guest, #40946) [Link]

The extra overhead didn't matter for low-performance applications.

The high-performance applications tended to be written to use ASTs to report I/O completion.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds