Types of System Calls in Operating System

  • System calls can be grouped roughly into six major categories: process control, file manipulation, device manipulation, information maintenance, communications and protection.

1.7.1 Process Control

  • A running program needs to be able to halt its execution either normally (end) or abnormally (abort).
  • If a system call is made to terminate the currently running program abnormally, or if the program runs into a problem and causes an error trap, a dump of memory is sometimes taken and an error message generated.
  • The dump is written to disk and may be examined by a debugger- a system designed to aid the programmer in finding and correcting bugs-to determine the cause of the problem.
  • Under either normal or abnormal circumstances, the operating system must transfer control to the invoking command interpreter.
  • The command interpreter then reads the next command.
  • In an interactive system, the command interpreter simply continues with the next command; it is assumed that the user will issue an appropriate command to respond to any error.
  • In a GUI system, a pop-up window might alert the user to the error and ask for guidance.
  • In a batch system, the command interpreter usually terminates the entire job and continues with the next job.
  • Some systems allow control cards to indicate special recovery actions in case an error occurs.
  • A control card is a batch-system concept. It is a command to manage the execution of a process.
  • If the program discovers an error in its input and wants to terminate abnormally, it may also want to define an error level.
  • More severe errors can be indicated by a higher-level error parameter.
  • It is then possible to combine normal and abnormal termination by defining a normal termination as an error at level 0.
  • The command interpreter or a following program can use this error level to determine the next action automatically.
  • A process or job executing one program may want to load and execute another program.
  • This feature allows the command interpreter to execute a program as directed by, for example, a user command, the click of a mouse, or a batch command.
  • An interesting question is where to return control when the loaded program terminates.
  • This question is related to the problem of whether the existing program is lost, saved, or allowed to continue execution concurrently with the new program.
  • Process control
    • end, abort
    • load, execute
    • create process, terminate process
    • get process attributes, set process attributes
    • wait for time
    • wait event, signal event
    • allocate and free memory
  • File management
    • create file, delete file
    • open, close
    • read, write, reposition
    • get file attributes, set file attributes
  • Device management
    • request device, release device
    • read, write, reposition
    • get device attributes, set device attributes
    • logically attach or detach devices
  • Information maintenance
    • get time or date, set time or date
    • get system data, set system data
    • get process, file, or device attributes
    • set process, file, or device attributes
  • Communications
    • create, delete communication connection
    • send, receive messages
    • transfer status information
    • attach or detach remote devices
  • If control returns to the existing program when the new program terminates, we must save the memory image of the existing program; thus, we have effectively created a mechanism for one program to call another program.
  • If both programs continue concurrently, we have created a new job or process to be multi programmed. Often, there is a system call specifically for this purpose (create process or submit job).
  • If we create a new job or process, or perhaps even a set of jobs or processes, we should be able to control its execution.
  • This control requires the ability to determine and reset the attributes of a job or process, including the job's priority, its maximum allowable execution time, and so on (get process attributes and set process attributes).
  • We may also want to terminate a job or process that we created (terminate process) if we find that it is incorrect or is no longer needed.
  • Having created new jobs or processes, we may need to wait for them to finish their execution.
  • We may want to wait for a certain amount of time to pass (wait time); more probably, we will want to wait for a specific event to occur (wait event).
  • The jobs or processes should then signal when that event has occurred (signal event).
  • Quite often, two or more processes may share data.
  • To ensure the integrity of the data being shared, operating systems often provide system calls allowing a process to lock shared data, thus preventing another process from accessing the data while it is locked.
  • Typically such system calls include acquire lock and release lock.
  • System calls of these types, dealing with the coordination of concurrent processes
    • The standard C library provides a portion o£ the system-call interface for many versions of UNIX and Linux.
    • As an example, let's assume a C program invokes the printf () statement.
    • The C library intercepts this call and invokes the necessary system call(s) in the operating system     -in this instance, the write() system call.
    • The C library takes the value returned by write() and passes it back to the user program.
  • There are so many facets of and variations in process and job control that we next use two examples-one involving a single-tasking system and the other a multitasking system -to clarify these concepts.
  • The MS-DOS operating system is an example of a single-tasking system.
  • It has a command interpreter that is invoked when the computer is started (Figure 10.a).
  • Because MS-DOS is single-tasking, it uses a simple method to run a program and does not create a new process.
  • It loads the program into memory, writing over most of itself to give the program as much memory as possible (Figure 10.b).


Figure 9. Standard C library handling of write().

  • Next, it sets the instruction pointer to the first instruction of the program.
  • The program then runs, and either an error causes a trap, or the program executes a system call to terminate.
  • In either case, the error code is saved in the system memory for later use.
  • Following this action, the small portion of the command interpreter that was not overwritten resumes execution.
  • Its first task is to reload the rest of the command interpreter from disk.
  • Then the command interpreter makes the previous error code available to the user or to the next program.
  • FreeBSD (derived from Berkeley UNIX) is an example of a multitasking system.
  • When a user logs on to the system, the shell of the user's choice is run.
  • This shell is similar to the MS-DOS shell in that it accepts commands and executes programs that the user requests.
  • However, since FreeBSD is a multitasking system, the command interpreter may continue running while another program is executed (Figure11).
  • To start a new process, the shell executes a fork() system call.
  • Then, the selected program is loaded into memory via an exec() system call, and the program is executed.
  • Depending on the way the command was issued, the shell then either waits for the process to finish or runs the process "in the background."
  • In the latter case, the shell immediately requests another command.
  • When a process is running in the background, it cannot receive input directly from the keyboard, because the shell is using this resource.
  • I/O is therefore done through files or through a GUI interface.
  • Meanwhile, the user is free to ask the shell to run other programs, to monitor the progress of the running process, to change that program's priority, and so on.
  • When the process is done, it executes an exit () system call to terminate, returning to the invoking process a status code of 0 or a nonzero error code.
  • This status or error code is then available to the shell or other programs.

 

Figure 10. MS-DOS execution. (a) At system startup   (b)  Running a program

1.7.2 File Management

  • We can, however, identify several common system calls dealing with files. We first need to be able to create and delete files.
  • Either system call requires the name of the file and perhaps some of the file's attributes.
  • Once the file is created, we need to open it and to use it.
  • We may also read, write, or reposition (rewinding or skipping to the end of the file, for example).
  • Finally, we need to close the file, indicating that we are no longer using it.
  • We may need these same sets of operations for directories if we have a directory structure for organizing files in the file system.
  • In addition, for either files or directories, we need to be able to determine the values of various attributes and perhaps to reset them if necessary.
  • File attributes include the file name, file type, protection codes, accounting information, and so on.
  • At least two system calls, get file attribute and set file attribute, are required for this function.
  • Some operating systems provide many more calls, such as calls for file move and copy.
  • Others might provide an API that performs those operations using code and other system calls, and others might just provide system programs to perform those tasks.
  • If the system programs are callable by other programs, then each can be considered an API by other system programs.

Figure 11. FreeBSD running multiple programs

1.7.3 Device Management

  • A process may need several resources to execute-main memory, disk drives, access to files, and so on.
  • If the resources are available, they can be granted, and control can be returned to the user process.
  • Otherwise, the process will have to wait until sufficient resources are available.
  • The various resources controlled by the operating system can be thought of as devices.
  • Some of these devices are physical devices (for example, disk drives), while others can be thought of as abstract or virtual devices (for example, files).
  • A system with multiple users may require us to first request the device, to ensure exclusive use of it.
  • After we are finished with the device, we release it.
  • These functions are similar to the open and close system calls for files.
  • Other operating systems allow unmanaged access to devices.
  • The hazard then is the potential for device contention and perhaps deadlock.
  • Once the device has been requested (and allocated to us), we can read, write, and (possibly) reposition the device, just as we can with files.
  • In fact, the similarity between I/0 devices and files is so great that many operating systems, including UNIX, merge the two into a combined file-device structure.
  • In this case, a set of system calls is used on both files and devices. Sometimes, I/0 devices are identified by special file names, directory placement, or file attributes.
  • The user interface can also make files and devices appear to be similar, even though the underlying system calls are dissimilar.
  • This is another example of the many design decisions that go into building an operating system and user interface.

1.7.4 Information Maintenance

  • Many system calls exist simply for the purpose of transferring information between the user program and the operating system.
  • For example, most systems have a system call to return the current time and date.
  • Other system calls may return information about the system, such as the number of current users, the version number of the operating system, the amount of free memory or disk space, and so on.
  • Another set of system calls is helpful in debugging a program.
  • Many systems provide system calls to dump memory.
  • This provision is useful for debugging. A program trace lists each system call as it is executed.
  • Even microprocessors provide a CPU mode known as single step, in which a trap is executed by the CPU after every instruction.
  • The trap is usually caught by a debugger. Many operating systems provide a time profile of a program to indicate the amount of time that the program executes at a particular location or set of locations.
  • A time profile requires either a tracing facility or regular timer interrupts.
  • At every occurrence of the timer interrupt, the value of the program counter is recorded.
  • With sufficiently frequent timer interrupts, a statistical picture of the time spent on various parts of the program can be obtained.
  • In addition, the operating system keeps information about all its processes, and system calls are used to access this information.
  • Generally, calls are also used to reset the process information (get process attributes and set process attributes).

1.7.5 Communication

  • There are two common models of inter process communication: the message passing model and shared-memory model.
  • In the message-passing model, the communicating processes exchange messages with one another to transfer information.
  • Messages can be exchanged between the processes either directly or indirectly through a common mailbox.
  • Before communication can take place, a connection must be opened.
  • The name of the other communicator must be known, be it another process on the same system or a process on another computer connected by a communications network.
  • Each computer in a network has a host name by which it is commonly known.
  • A host also has a network identifier, such as an IP address.
  • Similarly, each process has a process name, and this name is translated into an identifier by which the operating system can refer to the process.
  • The get hosted and get processed system calls do this translation.
  • The identifiers are then passed to the general purpose open and close calls provided by the file system or to specific open connection and close connection system calls, depending on the system's model of communication.
  • The recipient process usually must give its permission for communication to take place with an accept connection call.
  • Most processes that will be receiving connections are special-purpose daemons, which are systems programs provided for that purpose.
  • They execute a wait for connection call and are awakened when a connection is made.
  • The source of the communication, known as the client, and the receiving daemon, known as a server, then exchange messages by using read message and write message system calls.
  • The close connection call terminates the communication.
  • In the shared-Memory model, processes use shared memory create and shared memory attach system calls to create and gain access to regions of memory owned by the processes.
  • Recall that, normally, the operating system tries to prevent one process-from accessing another process's memory.
  • Shared memory requires that two or more processes agree to remove this restriction.
  • They can then exchange information by reading and writing data in the shared areas.
  • The form of the data is determined by the processes and are not under the operating system's control.
  • The processes are also responsible for ensuring that they are not writing to the same location simultaneously.
  • Both of the models just discussed are common in operating systems, and most systems implement both.
  • Message passing is useful for exchanging smaller amounts of data, because no conflicts need be avoided.
  • It is also easier to implement than is shared memory for inter computer communication.
  • Shared memory allows maximum speed and convenience of communication, since it can be done at memory transfer speeds when it takes place within a computer.
  • Problems exist, however, in the areas of protection and synchronization between the processes sharing memory.

1.7.6 Protection

  • Protection provides a mechanism for controlling access to the resources provided by a computer system.
  • Historically, protection was a concern only on multi-programmed computer systems with several users.
  • However, with the advent of networking and the Internet, all computer systems, from servers to PDAs, must be concerned with protection.
  • Typically, system calls providing protection include set permission and get permission, which manipulate the permission settings of resources such as files and disks.
  • The allow user and deny user system calls specify whether particular users can-or cannot-be allowed access to certain resources.

References

  1. MODERN OPERATING SYSTEMS by Andrew S. Tanenbaum, Second Edition
  2. The Operating System Concepts by Silberschatz, Galvin, Gagne, 8th Edition

Last modified: Sunday, 19 November 2017, 11:16 AM