The following designations are trademarks or registered trademarks of the organizations whose names follow in brackets:
ACMS, Alpha, DECintact, DECNET, DECSystem 10, DECthreads, DEQNA, Firefly, GNS, ULTRIX, VAX and VMS (Digital Equipment Corporation); ACTIVEX.COM (used by CNET under licence from owner – ACTIVEX.COM is an independent online service); Amoeba (Vrije Universiteit); ANSA (ANSA Internet Inc.); ARM and CHORUS (Acorn Computers); CORBA (Object Management Group); Courier and X25 (Xerox Corporation); HP-UX (Hewlett-Packard Company); Java, JavaScript, NFS, SunOS and XDR (Sun Microsystems, Inc.);
MC68000 (Motorola); MIPS (Silicon Graphics, Inc.); Netscape Navigator (Netscape Communications Corporation); Netware (Novell);
occam (INMOS Group of companies); Appletalk, Macintosh, MacOS X and OpenDoc (Apple Computers); MQSeries, OS/2, SNA and System 370 (International Business Machines Corporation); Pathway (Tandem); Itanium, Pentium, 8086, 80x86 and 860 (Intel);
Rendezvous (TIBCO); REXX (Oracle Corporation); Seagate Elite 23 and BarracudaATA IV (Seagate Technology Products); Tina-C (National Semiconductor Corporation); UNIX (X/Open Company Ltd); ActiveX, COM, DCOM, MS-DOS, .NET, Visual Basic, Windows 95, Windows 2000, Windows NT and Windows XP (Microsoft Corporation).
[ Team LiB ]
[ Team LiB ]
1.6 Security, protection and fault tolerance in system design
The aim of this book is to establish principles for understanding, designing and implementing software systems. System software runs indefinitely, typically supporting other running programs and users; the concept of concurrent activity is central. An operating system running on a single computer is an example of a system. A database management system, which runs above an operating system, is another. System structure, concurrency control and distribution are central concepts in system design. In this chapter we motivate the model of a (possibly distributed) 'concurrent system' by means of examples.
We shall start from an informal, intuitive definition of a concurrent system. Concurrent means 'at the same time'; the system software has to support many users or programs at the same time. The meaning of 'at the same time' is explored more deeply as we progress through the book, but initially we shall assume that the same measure of time holds throughout a system. A concurrent system must therefore handle separate activities which are in progress at the same time. To be a little more precise, we shall consider two activities to be concurrent if, at a given time, each is at some point between its starting point and finishing point.
The broad range of types of software system is introduced in this chapter and their essential characteristics are highlighted emphasizing structure, concurrency and distribution. Requirements for implementing these systems are drawn out in each case and the chapter concludes with a discussion of the requirements of concurrent software systems in general. The rest of the book is concerned with meeting these requirements.
We hope to build software systems which exploit new technology in emerging application areas. We need to be in a position to bring a good deal of processing power and memory to bear on a given problem and using a multicomputer system of some kind is likely to be the best way to do this. For this reason, this chapter includes a survey of the different kinds of overall system architecture on which a concurrent software system might run.
In some cases, a system is inherently concurrent since it is handling activities that can happen simultaneously in the world external to the computer system, such as users who want to run programs or clients who want to do bank transactions. For a system which supports many simultaneous users, the system designers may choose to load a separate copy of some system program, such as a compiler, for every user or may choose to have all users share a single copy. The shared system program is a simple example of a concurrent system.
Application programs are typically initiated by a user and run to completion. For certain applications it might be possible to work on parts of a problem in parallel by devising a concurrent algorithm for its solution. This is a valuable approach when an application involves a massive amount of computation and data and there is a real-time requirement for the result, such as in weather forecasting. These are potentially concurrent applications. At present, many problems of this type are solved, if at all, by sequential (rather than concurrent) algorithms on expensive, high-performance computers. A concurrent approach could improve matters in two ways. Either the same quality of result could be achieved at lower cost by using a number of inexpensive off-the-shelf computers, or a better model of the physical system could be built, perhaps giving rise to even more data to be processed but generating a more accurate result. Concurrent algorithms might also bring the solution of a wider range of problems within a reasonable budget. The methods of supporting concurrent activities within systems are equally applicable to supporting concurrent activities within applications.
Application programs are run by systems. We shall study how many applications may be run simultaneously by an operating system and how operating systems support concurrent applications.
[ Team LiB ]
[ Team LiB ]
1.1 Inherently concurrent systems
Systems which must respond to, or manage, simultaneous activities in their external environment are inherently concurrent and may broadly be classified as:
real-time and embedded systems (special-purpose operating systems);
operating systems (OSs);
distributed operating systems (the OS components are distributed);
database management and transaction processing systems (run above operating systems);
distributed, application-level services.
The implementation of a system may be centralized, running on a single computer (which may also be termed a host or node), or may be distributed over a number of computers. The user interface to a system may make its support for concurrent activities explicit.
1.1.1 Real-time and embedded systems
The special characteristic of real-time systems is that there are timing requirements which are dictated by the environment of the computer system. It may be essential, for example, for the computer system to respond to an alarm signal in some specific time, although it may be highly unlikely that such a signal will occur and it will never be predictable. The term 'hard real-time system' is used to indicate that the timing requirements are absolute. 'Soft real-time' indicates that failing to meet a deadline will not lead to a catastrophe.
Another useful distinction is between static and dynamic real-time systems. In a static system an analysis of the activities that must be carried out by the system can be done when the system is designed. In a dynamic real-time system requests may occur at irregular and unpredictable times and the system must respond dynamically and with guaranteed performance. Examples are given below.
It is worth emphasizing that 'real-time' does not always imply 'very fast indeed', but rather that timing requirements are known and must be guaranteed.
Examples of real-time systems are process control systems for power stations, chemical plants, etc., military command and control systems, hospital patient monitoring systems, spaceflight, aeroplane and car engine controllers, air traffic control systems, robot controllers, real-time image processing and display systems, videophones and many more.