In addition, the fact that services are provided by independent processes makes it easier to debug them, and also makes it possible to add and remove services while
the system is running.
But performance can be a problem
The price is overhead in communicating between the different modules. For example, when a user application wants to read a file, the system first has to switch to the file
system server. It also has to route messages back and forth between the application and the server.
user file system
microkernel application
server
hardware
11.4 Extensible Systems
Extensibility is required in order to handle new devices
It may be surprising at first, but the fact is that operating systems have to be extended after they are deployed. There is no way to write a “complete” operating system that
can do all that it will ever be asked to do. One reason for this is that new hardware devices may be introduced after the operating system is done. As this cannot be
anticipated in advance, the operating system has to be extended.
Exercise 146 But how does code that was compiled before the new device was added know how to call the routines that handle the new device?
It can also be used to add functionality
The case of hardware devices is relatively simple, and is handled by modules called device drivers that are added to the kernel. But once the concept is there, it can be
used for other things.
Several systems support loadable modules. This means that additional code can be loaded into a running system, rather than having to recompile the kernel and
reboot the system.
195
use requires indirection: to add system call or wrap existing system call, modify entries in system call table of trap handler iff wrapping, call original function. to add
functionality, add e.g. to table of supported file systems. can be loaded automatically as needed, and unloaded when falls out of use.
This leads to the option of application-specific customization
One of the functions of an operating system is to provide various useful abstractions to application programs. But it is impossible to anticipate all the needs of applications.
Moreover, different applications may have conflicting needs.
A solution to this problem is to allow applications to customize the operating sys- tem services according to their needs. A good example is provided by the Choices
research operating system [1]. This system is based on an object-oriented framework, and exports various classes to the user interface. Applications may write code that in-
herits part of the original operating system implementation, but replaces other parts with customized versions.
As a concrete example, consider the implementation of a semaphore. When a process performs the P operation, the operating system may need to block it if the
semaphore is currently not available. Thus many processes may become queued in the semaphore. The question is how to maintain this queue. Different implemen-
tations can emphasize speed, fairness, or consideration of process priorities. Rather than trying to anticipate and provide all these options, the operating system imple-
ments only one which seems generally useful. Applications that prefer another ap- proach can substitute it with their own implementation.
Exercise 147 Can an application be allowed to customize the system scheduler?
Bibliography
[1] R. H. Campbell, N. Islam, D. Raila, and P. Madany, “
Designing and implementing Choices: an object-oriented system in C++
”. Comm. ACM 369, pp. 117–126, Sep
1993. [2] A. Goel, L. Abeni, C. Krasic, J. Snow, and J. Walpole, “
Supporting time-sensitive applications on a commodity OS
”. In 5th Symp. Operating Systems Design Implementation
, pp. 165–180, Dec 2002. [3] I. Leslie, D. McAuley, R. Black, T. Roscoe, P. Barham, D. Evers, R. Fairbairns,
and E. Hyden, “
The design and implementation of an operating system to support distributed multimedia applications
”. IEEE J. Select Areas in Commun. 147,
pp. 1280–1297, Sep 1996. [4] R. F. Rashid, “
Threads of a new system
”. UNIX Review 48, pp. 37–49, Aug 1986.
196
Part IV
Communication and Distributed Systems
Most computers nowadays are connected to networks. The operating systems of these computers need to be able to interact. At a minimum, they should understand
the same communication protocols. Using these protocols, it is possible to create various services across machines, such as
• Send and receive e-mail. • Finger a user on a remote machine.
• “Talk” to a user on another machine interactively.
Incidently, these services are handled by daemons. Beyond simple interaction, system functions may actually be distributed across a
network. In this case, some computers are responsible for some functions, and only they handle these functions. If an application on another computer asks for such a
service, the request is sent across the network to the responsible computer. The pri- mary example is file servers, that contain large disks and store files for applications
running on many other machines. In some distributed systems, it may be possible to migrate applications from a loaded machine to a less-loaded one, in order to improve
response time. In this case, all the machines are “computation” servers.
This part in the notes explains how distributed systems are constructed, and how communication is performed.
Chapter 12
Interprocess Communication
Recall that an important function of operating systems is to provide abstractions and services to applications. One such service is to support communication among pro-
cesses, in order to enable the construction of concurrent or distributed applications. A special case is client-server applications, which allow clients applications to interact
with server applications using well-defined interfaces.
This chapter discusses high-level issues in communication: naming, abstractions and programming interfaces, and application structures such as client-server. The
next chapter deals with the low-level details of how bytes are actually transferred and delivered to the right place.
To read more: Communication is covered very nicely in Stallings [6], Chapter 13, especially Sections 13.1 and 13.2. It is also covered in Silberschatz and Galvin [4] Sections 15.5 and
15.6. Then, of course, there are whole textbooks devoted to computer communications. A broad introductory text is Comer [1]; more advanced books are tanenbaum [8] and stallings
[5].
12.1 Naming
