An Operating Systems Vade Mecum

The process interface 179When the process submits a Close service call, the device driver can archive anyremaining buffers in the cache. The slot in the active device array is then released byresetting InUse to false.5.4 Buffer depletionSince the kernel uses buffers to hold data that are in transit between processes and theoutside world, there is a possibility that these buffers will be depleted. For example, aprocess may try to write to a disk faster than the disk can accept information. Eventually,all the main-store buffers will be full. The process must then be blocked when it triesanother write request.The overflow situation becomes especially interesting in the case of terminals. Letus assume that there are ten terminals attached to the computer and ten processes, eachcommunicating with a terminal. Terminals accept information at a fairly slow rate. Thisrate can drop to zero if the user types a ‘‘stop terminal’’ character (typically S),which is intended to delay further output while the user reads what is currently on thescreen. Programs, in contrast, generally can accept information much faster than a usercan type it in. However, the rate at which a program accepts data may drop if it must calculatesome complex function before it is ready for new data. We will allow the user totype ahead in this case and store input inside the kernel until the process requests it.Finally, let us assume that characters to be written out or that are typed in are saved in 1-character buffers in the kernel and that there are only 1000 such buffers. This situation isdepicted in Figure 5.14.We will start with a straightforward policy: If a process wants to write a characterout, the character is put in a buffer until it can be written. If no buffers are available, theprocess is blocked. A character typed by the user is placed in a buffer until the associatedprocess requests to read it and is also echoed back to the terminal. If no buffers areavailable, the character is not echoed; instead, a G (which sounds a beep onmost terminals) is echoed.Our first problem arises as we try to implement this policy. Let’s assume that allthe buffers are in use and the user types a character. How can we echo Gexcept by placing the G character in a free buffer and scheduling it for output?To avoid this sort of traffic jam, we will refuse new characters from the users if we havefewer than ten buffers left. Then even if every user types a character simultaneously, wewill still have enough buffers to echo the G. We don’t have to worry about auser typing several characters faster than we can echo G’s because it is not possibleto type faster than the terminal can accept responses from the computer. We alsodon’t have to worry that the user might have stopped output and thereby prevented usfrom echoing characters: We release the stopped terminal whenever the user types anythingother than the stop character itself.Our next problem is that one user-process interaction can interfere with all theother users. Let’s assume that one process has tried to write more than 1000 characterswhile the terminal is in stop status. All our buffers become full after 1000 characters,and then we block that process. No other user or process can transmit informationbecause no buffers are left. It is not right to cause those users and processes to suffer