Libraries
| Depends on | IO • User |
|---|
Libraries are collections of code, usually around some common theme, providing functions which are likely to be useful to numerous different applications.
Most libraries provide user functions and can run entirely in user mode. Examples might include:
- Mathematical functions
- String processing functions
- …
So, why are they mentioned here?
Firstly, some libraries provide applications with an interface to a specific operating system. Thus a system-agnostic Java or C application can be linked with an appropriate library to run on Unix, Windows etc. The libraries (only) need to ‘understand’ the specific system calls for the particular underlying system.
Also, quite often, the application programmer will think of the library call as a system call. (“System” in Java…). Some libraries may intermediate the user and O.S. for efficiency, since a true system call can be expensive in processing time.
A couple of possible examples:
- A memory allocation function (
malloc()in C) may first request a ‘large’ quantity of RAM from the O.S. and pass only part of this back to the requester. Subsequent calls can then be supplied from the remainder until it runs out and a true system call is needed again. Although this is another software layer the time savings can significant; it probably wastes some extra fragments of memory though.
- When dealing with serial data streams it would be very inefficient to make a true system call to write each character. A library call like
putc()(in Cstdio.h) will typically accumulate characters in a buffer and only really write these at particular times. For example, writing to a file may accumulate a full disk ‘block’ before writing; output to the display may output at each <newline>.
There’s a demonstration of this principle in this article.
Implementation
Static Libraries
The simple way to incorporate a library is to link it into the application at compilation time; this includes the library code with the application program in the filestore. (A smart linker will just include the functions which are actually invoked!) This has the disadvantages that it increases the size of (every) object code file and, under many circumstances, there can be many copies of the same library code occupying physical memory at the same time: one in almost every process for some common functions. This consumes a valuable resource (i.e. memory).
An advantage is that, being self-contained, the object file does not depend on an appropriate system set-up.
The operating system is not involved.
Dynamic libraries
This term covers different schemes where the library code is not included in the application: it is loaded when the application is run. The advantages are:
- space saving – especially in disk files as the library does not need to be repeated in many applications.
- there can be savings in RAM too, with a shared library
- maintenance: an update to a dynamic library will apply to every program which uses it.
- no need for recompilation
- no need to release source code
Dynamic Loading
The process, once running can open the library (assuming it is available!) and extract the required functions. This is typically under explicit software control.
The library may already be present, which is where the operating system can be involved: there is an advantage in keeping only one copy, shared amongst processes.
Dynamic Linking
Here the application invokes an (external) dynamic linker (either at start-up or during execution) which identifies the required libraries and links the function addresses.
This is an operating system function. The libraries are loaded and integrated without the application being (particularly) aware of the process.
A shared library allows multiple different applications to share the same code, reducing the memory requirement. It comes with certain complications:
- the library code must be reentrant.
- the library code must be relocatable
(it may appear at different virtual addresses in different applications). - the library code needs to be linked dynamically (i.e. at run time);
sometimes the code will need to be loaded (and unloaded) dynamically. - only the O.S. knows how many processes (from zero, upwards) currently require a particular routine; that’s a reason for mentioning this topic here.
Perhaps the best known – perhaps ‘most notorious’ ? – implementation is Windows’ Dynamic-Link Library (DLL).
With any dynamic linking there must always be an assumption that the desired libraries are present and locatable at the right time. Failure to comply will result in an error.
As you might expect, Wikipedia will give you many more details.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 2.5, pages 75-77 |
|---|
