The Background Of The Operating System

Published Date: 02 Nov 2017

Process management is an integral part of any modern day operating system (OS). The OS must allocate resources to processes, enable processes to share and exchange information, protect the resources of each process from other processes and enable synchronization among processes. To meet these requirements, the OS must maintain a data structure for each process, which describes the state and resource ownership of that process, and which enables the OS to exert control over each process.

Multiprogramming systems explicitly allow multiple processes to exist at any given time, where only one is using the CPU at any given moment, while the remaining processes are performing I/O or are waiting.

The process manager is of the four major parts of the operating system. It implements the process abstraction. It does this by creating a model for the way the process uses CPU and any system resources. Much of the complexity of the operating system stems from the need for multiple processes to share the hardware at the same time. As a consequence of this goal, the process manager implements CPU sharing (called scheduling), process synchronization mechanisms, and a deadlock strategy. In addition, the process manager implements part of the operating system's protection and security.

A process is usually defined as the instance of the running program. Process management describes how the operating systems manage the multiple processes running at a particular instance of time.

Both operating systems provide complete isolation between simultaneous users. There are some key differences between the two which we will discuss in this paper.

2.0 Process Management In Unix

When we log on to a computer running UNIX, a shell process is started to service our commands. The UNIX operating system keeps track of the users and their processes and prevents processes from interfering with one another. The operating system does not come with any default interface for user interaction. However, the shell process on the computer running UNIX can connect to other computers to load third-party UIs.

Each process runs a single program and initially has a single thread of control. In other words, it has one program counter, which keeps track of the next instruction to be executed. Most versions of UNIX allow a process to create additional threads once it starts executing.

UNIX is a multiprogramming system, so multiple, independent processes may be running at the same time. Each user may have several active processes at once, so on a large system, there may be hundreds or even thousands of processes running.

Multitasking. UNIX is a multiprocessing, multiuser system. At any given point, you can have many processes running on UNIX. Consequently, UNIX is very efficient at creating processes. Unix has preemptive multitasking, in which time slices are allocated by a scheduler which routinely interrupts or pre-empts the running process in order to hand control to the next one. Almost all modern operating systems support preemption.

Multithreading. Most new UNIX kernels are multithreaded to take advantage of symmetric multiprocessing (SMP) computers. Initially, UNIX did not expose threads to programmers. However, POSIX has user-programmable threads. There is a POSIX standard for threads (called Pthreads) that all current versions of UNIX support.

Process hierarchy. When a UNIX-based application creates a new process, the new process becomes a child of the process that created it. This process hierarchy is often important, and there are system calls for manipulating child processes.

A process is the basic context within which all user-requested activity is

serviced within the operating system. To be compatible with other UNIX

systems, Linux must use a process model similar to those of other versions

of UNIX. Linux operates differently from UNIX in a few key places, however. In

this section, we review the traditional UNIX process model (Section A.3.2) and

introduce Linux's own threading model.

21.4.1 The fork() and exec() Process Model

The basic principle of UNIX process management is to separate two operations:

the creation of a process and the rum1.ing of a new program. A new process

is created by the fork() system call, and a new program is run after a call to

exec(). These are two distinctly separate functions. A new process may be

created with fork() without a new program being run-the new subprocess

simply continues to execute exactly the same program that the first (parent)

process was running. Equally, running a new program does not require that

a new process be created first: any process may call exec() at any time. The

currently rumung program is immediately terminated, and the new program

starts executing in the context of the existing process.

This model has the advantage of great simplicity. It is not necessary to

specify every detail of the environment of a new program in the system call that

runs that program; the new program simply runs in its existing environment.

If a parent process wishes to modify the environment in which a new program

is to be run, it can fork and then, still running the original program in a child

process, make any system calls it requires to modify that child process before

finally executing the new program.

Under UNIX, then, a process encompasses all the information that the

operating system must maintain to track the context of a single execution of a

single program. Under Linux, we can break down this context into a number of

specific sections. Broadly, process properties fall into three groups: the process

identity, environment, and context.

21.4.1.1 Process Identity

A process identity consists mainly of the following items:

Process ID (PID). Each process has a Lmique identifier. The PID is used to

specify the process to the operating system when an application makes a

system call to signal, modify, or wait for the process. Additional identifiers

associate the process with a process group (typically, a tree of processes

forked by a single user command) and login session.

Credentials. Each process must have an associated user ID and one or more

group IDs (user groups are discussed in Section 10.6.2) that determine the

rights of a process to access system resources and files.

21.4 813

Personality. Process personalities are not traditionally found on UNIX

systems, but under Linux each process has an associated personality

identifier that can slightly modify the semantics of certain system calls.

Personalities are primarily used by emulation libraries to request that

system calls be compatible with certain varieties of UNIX.

Most of these identifiers are under the limited control of the process

itself. The process group and session identifiers can be changed if the process

wants to start a new group or session. Its credentials can be changed, subject

to appropriate security checks. Howeve1~ the primary PID of a process is

unchangeable and uniquely identifies that process until termination.

21.4.1.2 Process Environment

A process's environment is inherited from its parent and is composed of two

null-terminated vectors: the argument vector and the enviromnent vector. The

argument vector simply lists the command-line arguments used to invoke the

running program; it conventionally starts with the name of the program itself.

The environment vector is a list of "NAME= VALUE" pairs that associates named

environment variables with arbitrary textual values. The environment is not

held in kernel memory but is stored in the process's own user-mode address

space as the first datum at the top of the process's stack.

The argument and environment vectors are not altered when a new process

is created; the new child process will inherit the environment that its parent

possesses. However, a completely new environment is set up when a new

program is invoked. On calling exec (),a process must supply the environment

for the new program. The kernel passes these enviromnent variables to the next

program, replacing the process's current environment. The kernel otherwise

leaves the environment and command-line vectors alone-their interpretation

is left entirely to the user-mode libraries and applications.

The passing of environment variables from one process to the next and the

inheriting of these variables by the children of a process provide flexible ways

to pass information to components of the user-mode system software. Various

important environment variables have conventional meanings to related parts

of the system software. For example, the TERM variable is set up to name the

type of terminal com1.ected to a user's login session; many programs use this

variable to determine how to perform operations on the user's display, such as

moving the cursor and scrolling a region of text. Programs with multilingual

support use the LANG variable to determine in which language to display

system messages for programs that include multilingual support.

The environment-variable mechanism custom-tailors the operating system

on a per-process basis, rather than for the system as a whole. Users can choose

their own languages or select their own editors independently of one another.

21.4.1.3 Process Context

The process identity and environment properties are usually set up when a

process is created and not changed until that process exits. A process may

choose to change some aspects of its identity if it needs to do so, or it may

alter its environment. In contrast, process context is the state of the running

814 Chapter 21

program at any one time; it changes constantly. Process context includes the

following parts:

Scheduling context. The most important part of the process context is its

scheduling context-the information that the scheduler needs to suspend

and restart the process. This information includes saved copies of all the

process's registers. Floating-point registers are stored separately and are

restored only when needed, so that processes that do not use floating-point

arithmetic do not incur the overhead of saving that state. The scheduling

context also includes information about scheduling priority and about any

outstanding signals waiting to be delivered to the process. A key part of the

scheduling context is the process's kernel stack, a separate area of kernel

memory reserved for use exclusively by kernel-mode code. Both system

calls and interrupts that occur while the process is executing will use this

stack.

Accounting. The kernel maintains accounting information about the

resources currently being consumed by each process and the total resources

consumed by the process in its entire lifetime so far.

File table. The file table is an array of pointers to kernel file structures.

When making file-I/O system calls, processes refer to files by their index

into this table.

File-system context. Whereas the file table lists the existing open files, the

file-system context applies to requests to open new files. The current root

and default directories to be used for new file searches are stored here.

Signal-handler table. UNIX systems can deliver asynchronous signals to

a process in response to various external events. The signal-handler table

defines the routine in the process's address space to be called when a

specific signal arrives.

Virtual memory context. The virtual memory context describes the full

contents of a process's private address space; we discuss it in Section 21.6.

21.4.2 Processes and Threads

Linux provides the fork() system call with the traditional functionality of

duplicating a process. Linux also provides the ability to create threads using the

clone() system call. However, Linux does not distinguish between processes

and threads. In fact, Linux generally uses the term task-rather than process or

thread-when referring to a flow of control within a program. When clone()

is invoked, it is passed a set of flags that determine how much sharing is to

take place between the parent and child tasks. Some of these flags are:

21.5

21.5 815

Thus, if clone() is passed the flags CLONE_FS, CLONE_VM, CLONE_SIGHAND,

and CLONE_FILES, the parent and child tasks will share the same file-system

information (such as the current working directory), the same memory space,

the same signal handlers, and the same set of open files. Using clone() in this

fashion is equivalent to creating a thread in other systems, since the parent task

shares most of its resources with its child task. However, if none of these flags is

set when clone () is invoked, no sharing takes place, resulting in functionality

similar to the fork() system call.

The lack of distinction between processes and threads is possible because

Linux does not hold a process's entire context within the main process data

structure; rather, it holds the context within independent subcontexts. Thus,

a process's file-system context, file-descriptor table, signal-handler table, and

virtual memory context are held in separate data structures. The process data

structure simply contains pointers to these other structures, so any number of

processes can easily share a subcontext by pointing to the same subcontext.

The arguments to the clone () system call tell it which subcontexts to copy,

and which to share, when it creates a new process. The new process always is

given a new identity and a new scheduling context. According to the arguments

passed, however, it may either create new subcontext data struch1res initialized

to be copies of the parent's or set up the new process to use the same subcontext

data structures being used by the parent. The fork() system call is nothing

more than a special case of clone() that copies all subcontexts, sharing none.

3.0 Process Management In Windows 7

Windows 7 has evolved greatly from its predecessors, such as Windows XP. It is now a preemptive multitasking operating system. As a result, Windows relies more heavily on threads than processes. (A thread is a construct that enables parallel processing within a single process.) Creating a new process is a relatively expensive operation while creating a new thread is not as expensive in terms of system resources like memory and time. Hence, multiprocess-oriented applications on UNIX typically translate to multithreaded applications on the Windows platform, thus saving such system resources as memory and time.

When a user logs on interactively to a computer running Windows 7, the Win32 subsystem’s Graphical Identification and Authentication dynamic-link library (GINA) creates the initial process for that user, which is known as the user desktop, where all user interaction or activity takes place. The desktop on the user's computer is loaded from the server. Only the user who is logged on has access to the desktop. Other users are not allowed to log on to that computer at the same time. However, if a user employs Terminal Services or Citrix, Windows 7 can operate in a server-centric mode just as UNIX does.

The Windows 7 operating system supports multiple users simultaneously through the command line and a GUI. The latter requires the use of Windows 7 Terminal Services. Windows 7 comes with a "single user" version that allows one user at a time (Windows 7) as well as a multiuser server version (Windows 7 Server). It is rare for a Windows 7 Server system to have multiple simultaneous command-line users.

In Windows 7, creating a new thread is very efficient. Windows 7 applications are capable of using threads to take advantage of SMP computers and to maintain interactive capabilities when some threads take a long time to execute.

Unlike UNIX, Windows 7 processes do not share a hierarchical relationship. The creating process receives the process handle and ID of the process it created, so a hierarchical relationship can be maintained or simulated if required by the application. However, the operating system treats all processes like they belong to the same generation. Windows 7 provides a feature called Job Objects, which allows disparate processes to be grouped together and adhere to one set of rules.

In Windows 7, a is an executing instance of an application, and a is a unit of code that can be scheduled by the operating system. Thus, a process contains one or more threads. A process is started when some other process calls the CreateProcess () routine. This routine loads any dynamic link libraries used by the process and creates a primary thread. Additional threads can be created by the CreateThread () function. Each thread is created with its own stack, which defaults to 1 MB unless specified otherwise in an argument to Create Thread(). Because some C run-time functions maintain state in static variables, such as errno, a multithread application needs to guard against unsynchronized access. The wrapper function beginthreadex () provides appropriate synchronization.

22.7.3.1 Instance Handles

Every dynamic link library or executable file loaded into the address space of

a process is identified by an; The value of the instance handle

is actually the virtual address where the file is loaded. An application can get

the handle to a module in its address space by passing the name of the module

to GetModuleHandle (). If NULL is passed as the name, the base address of

the process is returned. The lowest 64 KB of the address space are not used,

so a faulty program that tries to de-reference a NULL pointer gets an access

violation.

Priorities in the Win32 API environment are based on the Windows 7

scheduling model, but not all priority values may be chosen. Win32 API uses

four priority classes:

IDLE_PRIORITY _CLASS (priority level4)

NORMAL_PRIORITY _CLASS (priority level 8)

HIGH_PRIORITY _CLASS (priority levell3)

REAL TIME_PRIORITY _CLASS (priority level24)

Processes are typically members of the NORMALPRIORITY _CLASS unless the

parent of the process was of the IDLLPRIDRITY _CLASS or another class was

specified when CreateProcess was called. The priority class of a process

can be changed with the SetPriori tyClass () function or by passing of

an argument to the START command. For example, the command START

/REALTIME cbserver. exe would run the cbserver program in the REALTIME_

PRIDRITY _CLASS. Only users with the increase scheduling priority privilege

can move a process into the REALTIMLPRIORITY_CLASS. Administrators and

power users have this privilege by default.

22.7.3.2 Scheduling Rule

When a user is running an interactive program, the system needs to provide

especially good performance for the process. For this reason, Windows 7 has a

special scheduling rule for processes in the NORMALPRIORITY _CLASS. Windows

XP distinguishes between the foreground process that is currently selected on

the screen and the background processes that are not currently selected. When

a process moves into the foreground, Windows 7 increases the scheduling

quantum by some factor-typically by 3. (This factor can be changed via the

performance option in the system section of the control panel.) This increase

gives the foreground process three times longer to run before a time-sharing

preemption occurs.

896 Chapter 22

22.7.3.3 Thread Priorities

A thread starts with an initial priority determined by its class. The priority

can be altered by the SetThreadPriori ty() function. This function takes an

argument that specifies a priority relative to the base priority of its class:

THREAD_PRIORITY _LOWEST: base 2

THREAD_PRIORITY _BELOW_NORMAL: base - 1

THREAD_PRIORITY _NORMAL: base + 0

THREAD_PRIORITY _ABOVE_NORMAL: base + 1

THREAD_PRIORITY _HIGHEST: base+ 2

Two other designations are also used to adjust the priority. Recall from

Section 22.3.2.1 that the kernel has two priority classes: 16-31 for the realtime

class and 0-15 for the variable-priority class. THREAD_PRIORITY _IDLE sets

the priority to 16 for real-time threads and to 1 for variable-priority threads.

THREAD_PRIDRITLTIMLCRITICAL sets the priority to 31 for real-time threads

and to 15 for variable-priority threads.

As we discussed in Section 22.3.2.1, the kernel adjusts the priority of a

thread dynamically depending on whether the thread is I/0 bound or CPU

bound. The Win32 API provides a method to disable this adjustment via

SetProcessPriori tyBoost () and SetThreadPriori tyBoost () functions.

22.7.3.4 Thread Synchronization

A thread can be created in a the thread does not execute

until another thread makes it eligible via the ResumeThread() function. The

Suspend Thread () function does the opposite. These functions set a counter so

that if a thread is suspended twice, it must be resumed twice before it can nm.

To synchronize the concurrent access to shared objects by threads, the kernel

provides synchronization objects, such as semaphores and mutexes.

In addition, synchronization of threads can be achieved by use of the WaitForSingleObject()

and WaitForMultipleObjects() functions. Another

method of synchronization in the Win32 API is the critical section. A critical

section is a synchronized region of code that can be executed by only one thread

at a time. A thread establishes a critical section by calling Ini tializeCri ticalSection().

The application must call EnterCri ticalSection () before

entering the critical section and LeaveCri ticalSection () after exiting. These

two routines guarantee that, if multiple threads attempt to enter the critical

section concurrently, only one thread at a time will be permitted to proceed; the

others will wait in the EnterCri ticalSection () routine. The critical-section

mechanism is faster than using kernel-synchronization objects because it does

not allocate kernel objects until it first encounters contention for the critical

section.

22.7.3.5 Fibers

A is user-mode code that is scheduled according to a user-defined

scheduling algorithm. A process may have multiple fibers in it, just as it may

22.7 897

have multiple threads. A major difference between threads and fibers is that

whereas threads can execute concurrently, only one fiber at a tin1e is permitted

to execute, even on multiprocessor hardware. This mechanism is included in

Windows 7 to facilitate the porting of those legacy UNIX applications that

were written for a fiber-execution modeL

The system creates a fiber by calling either ConvertThreadToFi ber ()

or CreateFiber(). The primary difference between these functions is that

CreateFiber () does not begin executing the fiber that was created. To begin

execution, the application must call Swi tchToFiber (). The application can

terminate a fiber by calling DeleteFiber ().

22.7.3.6 Thread Pool

Repeated creation and deletion of threads can be expensive for applications and

services that perform small amounts of work in each instantiation. The thread

pool provides user-mode programs with three services: a queue to which work

requests may be submitted (via the QueueUserWorkitern() API), an API that

can be used to bind callbacks to waitable handles (RegisterWai tForSingleObj

ect ()),and APis to bind callbacks to timeouts (CreateTirnerQueue ()

and CreateTirnerQueueTirner () ).

The thread pool's goal is to increase performance. Threads are relatively

expensive, and a processor can only be executing one thing at a time no matter

how many threads are used. The thread pool attempts to reduce the number of

outstanding threads by slightly delaying work requests (reusing each thread

for many requests) while providing enough threads to effectively utilize the

machine's CPUs. The wait and timer-callback APis allow the thread pool to

further reduce the number of threads in a process, using far fewer threads than

would be necessary if a process were to devote one thread to servicing each

waitable handle or timeout.

4.0 Critical Comparison Of Process Management In UNIX And Windows 7

Both UNIX and Windows 7 OS’s are multitasking systems that support both processes and threads. They can be compared in several respects with regards to their process management features;

One key difference between UNIX and Windows 7 is the implementation of multiple users on one computer. When a user logs onto a UNIX system, a shell process is started to service their commands. Keeping track of users and their processes, a UNIX operating system is able to keep track of processes and prevent them from interfering with each other. This is extremely beneficial when all the processes run on the server, which demands a greater use of resources - especially with numerous users and sizeable applications.

Another main difference between UNIX and Windows 7 is the process hierarchy which UNIX possesses. When a new process is created by a UNIX application, it becomes a child of the process that created it. This hierarchy is very important, so there are system calls for influencing child processes. Windows 7 processes on the other hand do not share a hierarchical relationship. Receiving the process handle and ID of the process it created, the creating process of a Windows 7 system can maintain or simulate a hierarchical relationship if it is needed. The Windows 7 operating system ordinarily treats all processes as belonging to the same generation.

UNIX uses daemons, Windows 7 has service processes. Daemons are processes that are started when UNIX boots up that provide services to other applications. Daemons typically do not interact with users. A Windows 7 service is the equivalent to a UNIX daemon. When a Windows 7 system is booted, a service may be started. This is a long running application that does not interact with users, so they do not have a user interface. Services continue running during a logon session and they are controlled by the Windows 7 Service Control Manager.

UNIX has a novel approach to designing software. Since UNIX is open-sourced, it attracts some very intelligent programmers who develop many applications free of charge. With this in mind, many designers choose to resolve software problems by creating simpler tools that interconnect rather than creating large application programs. In contrast, Windows 7 applications are all proprietary and costly. With UNIX, each generation extends, rather than replaces the previous like Windows 7 it is rarely necessary to upgrade - old and new Unix are all compatible. The main reason for this is the way UNIX is built, which is on a solid theoretical foundation. There are many advantages to this, for instance, a book written 20 years ago that discusses programming UNIX can still be used today. Imagine trying to figure out how to run Windows 7 XP with a Window 3.1 manual - it can't be done.

OS / PROCESS

UNIX

WINDOWS 7

Multitasking

Very efficient at creating processes

Relies more on threads as opposed to processes

Multiple Users

Creates a shell process to service user commands.

Creates an initial process for a user known as the desktop.

Supports multiple simultaneous users through the command line and GUI.

Allows only one user to be logged in at a time.

Provides complete isolation between user processes.

Provides complete isolation between user processes.

Multithreading

Most UNIX kernels are multithreaded to make use of symmetric multiprocessing (SMP) computers.

Windows 7 applications are capable of using SMP computers.

Process Hierarchy

When a UNIX application creates a new process, the new process becomes a child of the parent process.

Windows 7 processes do not have a hierarchical relationship and all processes are treated equally

Table 1: Summary of Critical Comparison Of Process Management In UNIX And Windows 7

5.0 Conclusion

In summary, the best way to choose between UNIX and Windows is to determine organizational needs. If an organization uses mostly Microsoft products, such as Access, Front Page, or VBScripts, it's probably better to stick with Windows. But, if reliability, universal compatibility, and stability are a concern, UNIX would probably be the way to go.

In general, for a programmer or for an administrator, Unix provides more power and flexibility than Windows 7. For the less sophisticated user, Windows 7 can often more easily be installed and configured to run on cheaper hardware to run a desired 3rd party product. In short -- Unix is better, Windows 7 is easier for less sophisticated users.

Multitasking operating systems such as Windows 7 and UNIX must manage and control many processes simultaneously. Both Windows 7 and UNIX operating systems support processes and threads. Unix is much better at handling multiple tasks for a single user or for multiple users than Windows 7.

For each user, Unix in general, and especially Sun's Solaris provides many more utilities for manipulating files and data than Windows 7 does. For a corporate environment, Unix ( especially Solaris ) provides much more control for the administrator than Windows 7 does. Solaris, for example, enables the administrator to mirror or stripe data across several disks to minimize risk or optimize performance without 3rd party products.