Question

Consider one of the following pairs of scenarios. Buffered vs. non-buffered input 1. In your initial message, include the following information: Technical differences (e.g., mode of operation, method of implementation) in one versus the other 2. Unique challenges in using each of them in an application 3. Potential benefits and drawbacks of each 4. Finally, select a scenario in which you might need to choose between the types I/O.

Answer 1

In general, buffered I/O is faster but can be less reliable under certain circumstances.

Unbuffered I/O involves reading or writing data one element at a time: If the data stream is character-based, like a file on disk in a UNIX system, that means reading or writing the data character-by-character. Because the overhead involved in each I/O request is so great (due to the physical nature of the underlying device) and the number of requests is so high, this tends to be very slow. However, because all data accesses are resolved by the I/O device immediately, there's normally no way for the data "seen" by the process to ever disagree with the data actually in storage.

Buffered I/O involves reading or writing data in chunks: If a request to read a single character is made the system will actually read, say, a thousand characters from the device into a buffer in memory, then return just the first character from the buffer to the calling routine. Subsequent requests can be fulfilled entirely from the buffer (until it is depleted), which as it exists in memory can be accessed many times faster than can the device itself.

Buffered writes happen in a similar manner: Data written by a process is first accumulated in a buffer in memory until the buffer is full (or a time limit elapses), at which point the entire buffer is written to the device at once. Again, this reduces the number of real I/O operations involved and makes the system appear much faster.

Note that some devices lend themselves to buffered I/O naturally. This is true for instance of mechanical hard drives, which not only suffer from extremely high latency compared to regular memory but also permit data to be accessed only in multi-kilobyte chunks anyway.

So is it always better to use buffered I/O? Not necessarily. Buffered reads can yield incorrect results if the data in the buffer is stale, as can happen when one process modifies the data on the storage device but another continues to work with its (now out-of-date) copy in memory. Also, buffering writes can result in data loss, if for instance power to the computer is interrupted between data being written to the buffer in memory and the buffer's contents being output (flushed) to the device. Techniques are available to address both these scenarios.

You want unbuffered output when you already have large sequence of bytes ready to write to disk, and want to avoid an extra copy into a second buffer in the middle.

Buffered output streams will accumulate write results into an intermediate buffer, sending it to the OS file system only when enough data has accumulated (or flush() is requested). This reduces the number of file system calls. Since file system calls can be expensive on most platforms (compared to short memcpy), buffered output is a net win when performing a large number of small writes. Unbuffered output is generally better when you already have large buffers to send -- copying to an intermediate buffer will not reduce the number of OS calls further, and introduces additional work.

Unbuffered output has nothing to do with ensuring your data reaches the disk; that functionality is provided by flush(), and works on both buffered and unbuffered streams. Unbuffered IO writes don't guarantee the data has reached the physical disk -- the OS file system is free to hold on to a copy of your data indefinitely, never writing it to disk, if it wants. It is only required to commit it to disk when you invoke flush(). (Note that close() will call flush() on your behalf).

You want unbuffered output whenever you want to ensure that the output has been written before continuing. One example is standard error under a C runtime library - this is usually unbuffered by default. Since errors are (hopefully) infrequent, you want to know about them immediately. On the other hand, standard output is buffered simply because it's assumed there will be far more data going through it.

Another example is a logging library. If your log messages are held within buffers in your process, and your process dumps core, there a very good chance that output will never be written.

In addition, it's not just system calls that are minimized but disk I/O as well. Let's say a program reads a file one byte at a time. With unbuffered input, you will go out to the (relatively very slow) disk for every byte even though it probably has to read in a whole block anyway (the disk hardware itself may have buffers but you're still going out to the disk controller which is going to be slower than in-memory access).By buffering, the whole block is read in to the buffer at once then the individual bytes are delivered to you from the (in-memory, incredibly fast) buffer area.Keep in mind that buffering can take many forms, such as in the following example:

+-------------------+-------------------+
| Process A         | Process B         |
+-------------------+-------------------+
| C runtime library | C runtime library | C RTL buffers
+-------------------+-------------------+
|               OS caches               | Operating system buffers
+---------------------------------------+
|      Disk controller hardware cache   | Disk hardware buffers
+---------------------------------------+
|                   Disk                |
+---------------------------------------+