There is a need for the operating system to support separate activities at the application level (external to the operating system): the independent actions of its users or the multiple activities of a single user. The requirements that applications place on operating systems are dynamic and unpredictable.
There is a need for separate activities within the operating system: it must handle simultaneous requests from a number of its clients and it must handle simultaneously active devices.
There is a need for some of the separate activities to cooperate to achieve a common goal; an example is a printer spooler which prints files for users. It must take requests from the various users who want their files printed and liaise with those system components which know how to control the printer and locate files on the disk.
There is a need to manage competition for resources by separate activities.
Separate activities must be able to read and write system data structures without interference.
There is a need for a single task to be carried out as a whole, even when it involves a number of related subtasks. This must take into account potentially interfering concurrent activities and possible failures of the system.
The requirements on operating systems are wide ranging. Many aspects of concurrency control have traditionally been studied in the context of operating systems, since many problems were first encountered and defined in operating system design. Chapters 3, 5 and 6 expand on operating system functions and Chapter 4 shows how they support separate activities. Part II is concerned with some of the detailed problems of cooperation and competition between related activities.
Part III explores the problems associated with composite tasks. This area has traditionally been studied in the context of database management and transaction processing systems, since these systems have stronger requirements in this area than traditional operating systems. Operating systems may tell a user that the most recent version of a file has been lost after a system crash. If a database system tells a user that a transaction is done it must guarantee that this is the case and the results of the transaction must survive any subsequent system failure. In spite of this difference in emphasis the conceptual basis both for operating systems and for database systems is the same.
1.1.3 Window-based interfaces
Current workstations and terminals typically have graphical user interfaces (GUIs) or window systems. The advent of such systems has made concurrent activity explicit and natural to all computer users. Even low-end PC-based systems now run window interfaces. You may use the keyboard to type commands in some windows but more often you use the mouse device to move a cursor across the screen to click on a command button or select from a menu within an existing window, to cause a new window to be created or to open an iconified window for use.
For example, consider an email application with a window interface. To run the application you may type a command such as exmh in a command window, causing a new window to be created and the mail application to be made available for use via this window.
Alternatively, this may be done as part of your login procedure for an application such as email which is part of your working environment.
A window may be open or iconified and may be moved between these states by a mouse click.
Suppose you wish to send some mail and click on the appropriate command button. An empty mail template will appear in a new window and you may proceed to type a message. Part-way through you notice that new mail has arrived (by means of a flag and bleep) and click in the original mail window on the 'incorporate new mail' button. One incoming message may need a quick response so you click on 'reply' and get another new window with a reply template. At this stage the mail application has generated three windows and you may move between them at will. That is, the mail application has generated three concurrent activities.
We are familiar with a much higher degree of concurrent activity than this when using window-based interfaces. One may move freely among windows within and between applications. One may also wish to have concurrent activity associated with a single window. For example, one may click on a button to 'purge all mail folders' of messages that have been deleted but not yet removed from the system.
This takes some time and in parallel with this background activity one wishes to use other commands, such as reading messages or incorporating new ones that arrive.
1.1.4 Database management and transaction processing systems
Database applications are concerned with large amounts of persistent data, that is, data on permanent storage devices that exists independently of any running program. A typical user of a database system wants to make queries about the data, such as 'what is the current level of my bank account' or 'list the owners who live in Cambridge of purple Ford cars manufactured in 1990'. The owners of the database are concerned with keeping it up to date and will want to make updates. We assume a database management system (DBMS) which is responsible for interacting with users and organizing the reading and writing of the database to satisfy their requirements. The DBMS is a concurrent system since it may have to handle several clients simultaneously. The term transaction is used for a request from a client to a DBMS.
There are many uses for databases. Commercial systems include banking, airline and other booking systems, stock control for retailing, records of employees, and so on. Engineering systems cover such things as CAD systems, VLSI design and components databases for manufacturing. Statistical databases are held of population census data, for weather forecasting, etc. Public databases are held by police, health and social service institutions. There are also library and other specialized reference systems with expert systems to assist in the formulation of queries to extract the required information from specialized databases.
In applications where it is not critical that at all times the data appears to be up to date to the current instant, updates may be batched and run when convenient, perhaps overnight. This approach simplifies the management of the database enormously and is likely to be used if at all possible. Many of the problems associated with concurrent access are avoided by this means. For example, users may accept that the value given for the balance of a bank account is not up to date; the value at the end of the previous working day may be output with a clear indication of the time at which the value was valid. There is no guarantee in such a system that there is sufficient money in an account to cover a withdrawal. The trend is towards more up-to-date and interactive use of banking databases. Stock control in a supermarket might be managed on a daily basis with consolidation of purchases and reordering of stock carried out overnight.
In some systems the activities of reading and updating data are closely related and updates cannot be deferred. It would be impossible to run an airline or theatre reservation system with an overnight batched update policy. You need to know immediately whether you have booked a seat and not tomorrow morning, and therefore each transaction needs to see the up-to-date system state. Other examples of transaction processing systems are the international automatic teller machine (ATM) network service, which provides cash dispensing and other banking services world wide, and point of sale terminals. Both are discussed in Chapter 30.
There is scope for concurrency in database applications because of simultaneous requests from clients. In some kinds of database different clients are unlikely to require access to the same part of the database; it is unlikely that anyone else will be attempting to access my medical record at the same time as my doctor. Concurrent access is desirable for a fast response to queries and there are unlikely to be conflicting requests, that is, requests that attempt to update and read the same part of the database at the same time. Any number of transactions which only require to read the database may be run in parallel. If it is possible to update the database as well as read it, the DBMS must ensure that transactions do not interfere with each other.
In order to respond to queries in the timescale required, data will be copied from secondary storage (such as disk) into main memory and reads and updates will use the main memory copy. This introduces the potential problem that the copy of the data held on secondary storage becomes out of date. If the system crashes, the contents of main memory may be lost; for example, a power failure causes loss of main memory. The users of the system may have gone away in the belief that their transactions are complete and their results securely recorded. The management system must ensure that this is the case, even if writing information out to disk slows the system down. A transaction system must therefore support concurrent access and allow for system failure at any time.
Figure 1.5(a) shows the components of a transaction processing system for airline bookings. Many booking clerks can be acting simultaneously on behalf of their clients to book seats on flights recorded in a database. The administration also makes changes to the database. Figure 1.5(b) illustrates the world-wide nature of such a system. The diagram shows some of the components of the SITA (Société Internationale de Télécommunications Aéronautiques) private network as it was in the 1970s (Chou, 1977). Even then, over 200 airlines were members of this non-profit cooperative organization.
Figure 1.5. Airline booking systems. (a) Components. (b) Part of the early SITA private network.
The kind of problem addressed in Part II is to book a seat on a flight correctly; it is booked but not double-booked (assuming that the owners do not have an over-booking policy). The kind of problem addressed in Part III is how to implement a system which can automate the booking of an itinerary consisting of a number of connecting flights or none at all; if one connection can't be booked then none of the others are.
Requirements
The requirements for building transaction processing and database management systems that have emerged from the above discussion may be summarized as follows:
There is a need to support separate activities.
There is a need to ensure that the separate activities access and update common data without interference.
There is a need to ensure that the results of transactions are recorded permanently and securely before the user is told that an operation has been done.
1.1.5 Middleware
Distributed systems have become commonplace since first WANs and later LANs (since the late 1970s) allowed network-based distributed software to be developed. Support for distributed programs is now a common requirement and we expect to be able to run widely distributed applications (or services) such as electronic mail, network news or a web browser. They should run irrespective of the hardware or operating system we are using; that is, we expect to be able to work in a heterogeneous environment. More generally, industrial and commercial companies need interworking between their distributed components; for example, sales, stock control and invoicing may take place in geographically separate locations.
The idea is to build a layer of software (middleware) above the heterogeneous operating systems to present a uniform platform above which distributed applications can run. This simplifies the development of distributed applications by removing the need to port each application to a range of operating systems and hardware.
The components of a distributed program may run concurrently and, as we have seen in previous sections, various applications may run concurrently in each component of a distributed system.
1.1.6 Distributed systems: The World Wide Web
In 1990 Tim Berners-Lee developed a prototype hypermedia system called the World Wide Web (WWW). The original application domain had been nuclear physics at CERN, Switzerland. The novel aspect of the system was that cross-network communication formed an integral part of the system, thus creating the potential for transferring hypermedia pages without restriction 'world wide'.
In 1993 the Mosaic browser was developed by NCSA (the University of Illinois' National Center for Supercomputing). This provided a convenient window-based interface for the hypermedia transfer system. Since then the growth of the WWW has been explosive. Huge numbers of companies, universities and individuals have built information servers that anyone with a web browser can read.
Each page may contain text, images and links to other pages. A page is created using a hypertext markup language (HTML) which is similar to the standard markup language SGML but also contains instructions on how the page should be displayed. Each page is identified 'world wide' by a name called a universal resource locator (URL) which forms part of any link to that page. Although the link information appears in the HTML we do not see this in the page we view. Here certain words or images are highlighted (made 'active') so that when we click on them the current page is replaced by the page to which the link refers. To achieve this, the browser contacts the server which holds the page named in the link and transfers it for viewing in the browser. The protocol used between the web browser and web server to achieve this is called the hypertext transfer protocol (http).
Each client operates sequentially, viewing a page at a time. Any given server may receive any number of concurrent requests for pages;
another example where a server may have many simultaneous clients. As use of the web extends we shall increasingly see large databases accessible through web interfaces, thus compounding the need for many clients to have their requests served concurrently.
Animations can be added to web pages, typically written in the Java programming language. Here
concurrent processing may be used at the client to speed up the animation and to allow it to occur in parallel with user interaction with the page, for example when the page represents a form to be filled in.
[ Team LiB ]
[ Team LiB ]
1.2 Supporting potentially concurrent applications
We now move from systems which are inherently concurrent to applications which might benefit from concurrent implementation. Parallel algorithms are not presented in detail. Rather, the aim is to show the requirements for operating system support of separate but related concurrent activities that will work together to achieve some result. It is also important to investigate the requirement for some degree of interaction between the parallel computations.
The general motivation for exploiting potential concurrency in an application is that some or all of the following are the case:
there is a large amount of computing to be done;
there is a large amount of data to be processed;
there is a real-time requirement for the result;
hardware is available for running the potentially concurrent components in parallel.
First, some general approaches to obtaining a concurrent solution to a problem are described.
1.2.1 Replicated code, partitioned data
Perhaps the simplest approach is to use a sequential algorithm but to partition the data. Figure 1.6 shows the general idea. If all the components must run to completion the overall time taken is that of the longest component (the other components have run in parallel and have finished before the longest one) plus the overhead of initiating the parallel computations and synchronizing on their completion. The speed-up achieved therefore depends on being able to divide the computation into pieces with approximately equal computation time. This is because we have assumed that the total amount of data processing to be done is the same whether it is done sequentially or in parallel.
If we can divide the computation into components which require the same amount of computation time we have maximized the concurrency in the execution of the algorithm.
Figure 1.6. Replicated code, partitioned data.
Examples of problems which are suited to this static partitioning of data are as follows:
finding all the roots of a given function;
finding the turning points of a given function;
searching for specific values in data which has no ordering related to the values required; for example, the data may be records about people which are ordered according to their surnames. You are searching for people with a specific value in some field of their record, for example, those with an Australian grandparent.
A parallel algorithm for searching might be particularly suitable for large amounts of data, some of which is in main memory and some on disk. While one parallel activity waits for more data to be brought in from disk, another can proceed with processing data in main memory.
In some applications, once a solution is found by one component all the others can cease their activity. An example is a search for a single solution to a problem or query. In this case, once the solution is found all the components which are still executing should be stopped. The system mechanisms should make it possible to do this.
1.2.2 Pipelined processing
Another simple approach is the pipeline. If the total function to be applied to the data can be divided into distinct processing phases, different portions of data can flow along from function to function. Figure 1.7 shows a four-stage pipeline. An example is a compiler with phases for lexical analysis, parsing, type checking, code generation and so on. As soon as the first program or module has passed the lexical analysis phase it may be passed on to the parsing phase while the lexical analyser starts on the second program or module.
Figure 1.7. A four-stage pipeline.
The requirements here are for the separate activities executing the various phases to be able to synchronize with each other: to wait for new data to become available or to wait for the next phase to finish processing its current data.
1.2.3 Tree-structured algorithms
Many algorithms can be represented by a tree structure. For example, the evaluation of a function for given arguments may often be split into the evaluation of two (or more) subfunctions, which in turn can be split … In this case there is potential for parallel evaluation each time a branch is made as each subfunction must deliver its result to contribute to the higher-level evaluation.
Certain problems require that every branch must be evaluated in full. In other applications the tree structure is a way of dividing a search space where only one solution is required. The whole space should be traversed only if no solution exists. As soon as a solution is found the algorithm should terminate. Again, as discussed in Section 1.2.1, ongoing executions (and the process of creating new ones) should be stopped.
In other cases, such as speech recognition, the parallel branch traversals may represent alternative possibilities for a solution. Each branch has an associated probability of matching the solution and the requirement is to produce the combination of branches with the
In other cases, such as speech recognition, the parallel branch traversals may represent alternative possibilities for a solution. Each branch has an associated probability of matching the solution and the requirement is to produce the combination of branches with the