USER THREAD

User threads are supported above the kernel and are implemented by a thread library at the user level. The library provides support for thread creation, scheduling, and management with no support from the kernel. Because the kernel is unaware of user-level threads, all thread creation and scheduling, are done in user space without the need for kernel intervention.

MULTITHREADING MODELS

Many systems provide support for both user and kernel threads, resulting in different multithreading models. There are three common types of threading implementation:

1. Many-to-one Model - maps many user-level threads to one kernel thread.

2. One-to-one Model - maps each user thread to a kernel thread. It provides mode concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call.

3. Many-to-many Model - The many-to-many model multiplexes many user-level threads to a smaller or equal number of kernel threads. The number of kernel threads may be specific to either a particular application or a particular machine.

THREAD LIBRARY

The threads library allows concurrent programming in Objective Caml. It provides multiple threads of control (also called lightweight processes) that execute concurrently in the same memory space. Threads communicate by in-place modification of shared data structures, or by sending and receiving data on communication channels.
The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes.

KERNEL THREAD

Kernel threads consist of a set of registers, a stack, and a few corresponding kernel data structures. When kernel threads are used, the operating system will have a descriptor for each thread belonging to a process and it will schedule all the threads. Unlike processes, all threads within a process share the same address space. Similar to processes, when a kernel thread makes a blocking call, only that thread blocks. All modern machines support kernel threads, most often via the POSIX threads interface ``pthreads''. Some dedicated parallel machines support kernel threads poorly or not at all. For example, the Blue Gene/L microkernel does not support pthreads.

The purported advantage of kernel threads over processes is faster creation and context switching compared with processes. For shared-memory multiprocessor architectures, the kernel is able to dispatch threads of one process on several processors, which leads to automatic load balancing within the nodes. For parallel programming, threads allow different parts of the parallel program to communicate by directly accessing each others' memory, which allows very efficient, fine-grained communication.

Kernel threads share a single copy of the entire address space, including regions such as global data that may cause conflicts if used by multiple threads simultaneously. Threads can also cause unintentional data sharing, which leads to corruption and race conditions. To avoid this unintentional sharing, programs must often be modified to either lock or access separate copies of common data structures. Several very widely used language features are unsafe when used with threads, such as the use of global and static variables, or the idiom of returning a reference to a static buffer. Especially with large existing codebases with many global variables, this makes kernel threads very difficult to use because in most implementations of kernel threads, it is not possible to assign each thread a private set of global variables.

Kernel threads are considered ``lightweight,'' and one would expect the number of threads to only be limited by address space and processor time. Since every thread needs only a stack and a small data structure describing the thread, in principle this limit should not be a problem. But in practice, we found that many platforms impose hard limits on the maximum number of pthreads that can be created in a process. Table 2 in Section 4 shows the practical limitations on pthreads on several stock systems.

In particular, operating system kernels tend to see kernel threads as a special kind of process rather than a unique entity. For example, in the Solaris kernel threads are called ``light weight processes'' (LWP's). Linux actually creates kernel threads using a special variation of fork called ``clone,'' and until recently gave each thread a separate process ID. Because of this heritage, in practice kernel threads tend to be closer in memory and time cost to processes than user-level threads, although recent work has made some progress in closing the gap, including K42 [5] and the Native POSIX Threading Library (NPTL) and Linux O(1) scheduler.

BENEFITS OF MULTI-THREADED PROCESS

Multi-threaded programs can improve performance compared to traditional parallel programs that use multiple processes. Furthermore, improved performance can be obtained on multiprocessor systems using threads.

Managing Threads

Managing threads; that is, creating threads and controlling their execution, requires fewer system resources than managing processes. Creating a thread, for example, only requires the allocation of the thread's private data area, usually 64 KB, and two system calls. Creating a process is far more expensive, because the entire parent process addressing space is duplicated.
The threads library API is also easier to use than the library for managing processes. Thread creation requires only the pthread_create subroutine.

Inter-Thread Communications

Inter-thread communication is far more efficient and easier to use than inter-process communication. Because all threads within a process share the same address space, they need not use shared memory. Protect shared data from concurrent access by using mutexes or other synchronization tools.
Synchronization facilities provided by the threads library ease implementation of flexible and powerful synchronization tools. These tools can replace traditional inter-process communication facilities, such as message queues. Pipes can be used as an inter-thread communication path.

Multiprocessor Systems

On a multiprocessor system, multiple threads can concurrently run on multiple CPUs. Therefore, multi-threaded programs can run much faster than on a uniprocessor system. They can also be faster than a program using multiple processes, because threads require fewer resources and generate less overhead. For example, switching threads in the same process can be faster, especially in the M:N library model where context switches can often be avoided. Finally, a major advantage of using threads is that a single multi-threaded program will work on a uniprocessor system, but can naturally take advantage of a multiprocessor system, without recompiling.

Limitations

Multi-threaded programming is useful for implementing parallelized algorithms using several independent entities. However, there are some cases where multiple processes should be used instead of multiple threads.
Many operating system identifiers, resources, states, or limitations are defined at the process level and, thus, are shared by all threads in a process. For example, user and group IDs and their associated permissions are handled at process level. Programs that need to assign different user IDs to their programming entities need to use multiple processes, instead of a single multi-threaded process. Other examples include file-system attributes, such as the current working directory, and the state and maximum number of open files. Multi-threaded programs may not be appropriate if these attributes are better handled independently. For example, a multi-processed program can let each process open a large number of files without interference from other processes.

THREAD

SINGLE THREADED PROCESS

A single thread can control the execution on a Maurer machine of any executable finite-state thread stored in the memory of the Maurer machine. We also relate stored threads with programs as considered in the program algebra of Bergstra et al. The work is intended as a preparation for the development of a formal approach to model micro-architectures and to verify their correctness and anticipated speed-up results.

MULTI-THREADED PROCESS

Multiple threads can be executed in parallel across many computer systems.

This is multithreading, and generally occurs by time slicing (similar to time-division multiplexing) across the computer systems. However, in a single processor environment, the processor 'context switches' between different threads. In this case, the processing is not literally simultaneous, for the single processor is really doing only one thing at a time. This switching can happen so fast as to give the illusion of simultaneity to an end user.

For instance, many PCs may only contain one processor core, but one can run multiple programs at once, such as typing in a document editor while listening to music in an audio playback program. Although the user experiences these things as simultaneous, in truth, the processor quickly switches back and forth between these separate processes. On a multiprocessor or multi-core system, now coming into general use, threading can be achieved via multiprocessing, where different threads and processes can run literally simultaneously on different processors or cores.

Threads exist within a process - every process has at least one thread, the 'main' thread. Threads share the process's resources, including memory and open files. This makes for efficient, but potentially problematic, communication.

PROCEDURE-CONSUMER EXAMPLE

• PROCEDURE

A Procedure encapsulates a task composed of Steps (and possibly, SubSteps). Procedures are usually performed sequentially, unless individual Steps direct the reader explicitly.
Often it is important to assure that certain conditions exist before a procedure is performed, and that the outcome of the procedure matches the expected results. DocBook does not provide explicit semantic markup for these pre- and post-conditions. Instead, they must be described as steps (check the pre-conditions in the first step and the results in the last step), or described outside the body of the procedure.

• CONSUMER

Consumer is a broad label that refers to any individuals or households that use goods and services generated within the economy. The concept of a consumer is used in different contexts, so that the usage and significance of the term may vary.

BUFFERING

Explicit control of buffering is important in many applications, including ones that need to deal with raw devices (such as disks), ones which need instantaneous input from the user, or ones which are involved in communication. Examples might be interactive multimedia applications, or programs such as telnet. In the absence of such strict buffering semantics, it can also be difficult to reason (even informally) about the contents of a file following a series of interacting I/O operations.
Three kinds of buffering are supported: line-buffering, block-buffering or no-buffering. These modes have the following effects. For output, items are written out from the internal buffer according to the buffer mode:

• line-buffering: the entire buffer is written out whenever a newline is output, the buffer overflows, a flush is issued, or the handle is closed.
• block-buffering: the entire buffer is written out whenever it overflows, a flush is issued, or the handle is closed.
• no-buffering: output is written immediately, and never stored in the buffer.

ZERO CAPACITY

Communication over a noisy quantum channel introduces errors in the transmission that must be corrected. A fundamental bound on quantum error correction is the quantum capacity, which quantifies the amount of quantum data that can be protected. We show theoretically that two quantum channels, each with a transmission capacity of zero, can have a nonzero capacity when used together. This unveils a rich structure in the theory of quantum communications, implying that the quantum capacity does not completely specify a channel's ability to transmit quantum information.

BOUNDED CAPACITY

The capacity of discrete-time, non-coherent, multipath fading channels is considered. It is shown that if the delay spread is large in the sense that the variances of the path gains do not decay faster than geometrically, then capacity is bounded in the signal-to-noise ratio.

UNBOUNDED CAPACITY

The capacity of discrete-time, noncoherent, multipath fading channels is considered. It is shown that if the variances of the path gains decay faster than exponentially, then capacity is unbounded in the transmit power.

SYNCHRONIZATION

• BLOCK SEND

A blocking send can be used with a non-blocking
receive, and vice-versa,

e.g.,
MPI_Isend
MPI_Recv

• NONBLOCKING SEND

Non-blocking sends can use any mode -
synchronous, buffered, standard or ready.

Separate communication into three phases:

1. Initiate non-blocking communication (“post” a
send or receive)

2. Do some other work not involving the data in
transfer
– Overlap calculation and communication
– Latency hiding

3. Wait for non-blocking communication to complete

• BLOCKING RECEIVE

A blocking receive returns as soon as the data is ready in the receive buffer.

• NONBLOCKING RECEIVE

A non-blocking send returns as soon as possible, that is, as soon as it has posted the send. The buffer might not be free for reuse.

C:
int MPI_Irecv(void *buf, int count, MPI_Datatype datatype,
int source, int tag, MPI_Comm comm, MPI_Request
*request)
Fortran:
CALL
MPI_IRECV(BUF,COUNT,DATATYPE,SOURCE,TAG,COMM,REQUEST,IER
ROR)

BUF(*)
INTEGER COUNT,DATATYPE,SOURCE,TAG,COMM
INTEGER REQUEST,IERROR

INDIRECT COMMUNICATION

Indirect communication is used to attack, manipulate, or defend one's self.

By comparison, indirect communication conceals one's true position or feelings. There are may ways to be indirect, an obvious example is sarcasm. If you don't like someone's clothes and you say (in a sarcastic tone) "I like your clothes", the literal meaning and implied meaning are opposite.While direct communication has a goal of cooperation, indirect communication has a goal of hurting or manipulating another person, or protecting one's self. Below is an incomplete list of some different forms of indirect communication, grouped into attacks and defenses, along with a description.

personal attacks:
1.)name calling -- "You're a pig!". The purpose is to hurt the other person's feelings. If you were being direct, you might say "I'm angry at you, and I think you're a bad person.". This is truthful, but less likely to hurt the other person's feelings (if that is your goal). Note that name calling does not require any response from the other person...it's not a question, so no reply is required.

2.)belligerence -- "Why won't you do it?! Huh?! Why not?!?" Repeatedly demanding another person submit to your demands. An example of a direct response might be "I've already answered you, and I'm not going to answer you again. We can talk about something else, or I'm done talking to you."

3.)sarcasm -- Using an affected tone and saying the opposite of what you mean. Sarcasm can be used to mock or insult another person, although it can also be used purely for humorous effect.

4.)contempt -- A harsh and hostile tone of voice that expresses contempt for the person you are speaking to (or about). This is one of the "four horsemen of the apocalypse" for predicting divorce cited by John Gottman (see below).

5.)yelling -- Using an unnecessarily loud volume for effect. An example of a direct response might be to say "Please don't yell, I can hear you fine."

6.)insinuation -- Implying what you mean with suggestive statements. For example, "If it's not your fault, who's fault is it!?!". An example of a direct response might be to say "Are you implying I am to blame?"

defensiveness:

1.)defensive -- anything said with a defensive tone of voice, a high-pitched tone that is understood to deflect blame. For example, imaging the pitch used when a person says "What's your problem? I was only trying to help!". People are generally not aware of it when they are using a defensive tone of voice, but it's important to be aware of the tone of voice you are using if you want to avoid being defensive.

2.)dismissive -- To negatate another person's problem or statement. For example, saying "so what?"

3.)minimizing -- to reduce or de-value another person's problem by characterizing it as less than it is. For example, saying "It's only a scratch, you'll survive" when someone is hurt or injured.

4.)stonewalling -- obstructing another person's questions. Giving only evasive, dismissive, or vague responses to another perosn, making no effort to answer their questions but trying to wear them down/frustrate them.

INTERPROCESS COMMUNICATION

DIRECT COMMUNICATION

Direct communication is the most effective means of communication when trying to cooperate.

When communication is direct, a person means exactly what they say. There is no implied meaning, insinuation, or mixed message. Think of a scientist saying “The results of the experiment are positive”, or a journalist saying ”The accident occurred at 6pm”; this is direct communication. When you say "I like your clothes", and you are being direct, you mean you like the other person's clothes. People can communicate how they feel by being direct. For example, "I feel hurt that you didn't meet me yesterday" (this is sometimes called an "I-statement").
When being direct, the speaker's tone of voice is usuall "plain" (even monotome), because they are not using a sarcastic or defensive tone (or any other inflection that creates a mixed message). Direct communication is the only form of communication in many fields, such as science, journalism, and in the legal system (a defendant would not plead guilty in court sarcastically, because the sarcastic tone would be disregarded and it would count as a real guilty plea).
In all important matters in society, people use direct communication. For example, when an airplane communicates with air traffic control, they say directly and exactly what they mean, in very specific terms. They don't use sarcasm or imply things, since the situation is too important to allow for any misunderstanding.

COOPERATING PROCESSES

Advantages of process cooperation

• Information sharing
• Computation speed-up
• Modularity
• Convenience

Independent process cannot affect/be affected by the execution of another process, cooperating ones can

Issues

• Communication
• Avoid processes getting into each other’s way
• Ensure proper sequencing when there are dependencies

Common paradigm: producer-consumer

• unbounded-buffer - no practical limit on the size of the buffer
• bounded-buffer - assumes fixed buffer size

INTERPROCESSES COMMUNICATION

For communication and synchronization

• Shared memory
• OS provided IPC

Message system

• no need for shared variable
• two operations
• send(message) – message size fixed or variable
• receive(message)

If P and Q wish to communicate, they need to

• establish a communication link between them
• exchange messages via send/receive

Implementation of communication link

• physical (e.g., shared memory, hardware bus)
• logical (e.g., logical properties)
  4

OPERATION ON PROCESS

a.)PROCESS CREATION

Process creation is only the first management action performed by the OS on the process. Since the process will use the resources made available by the OS, further OS activity will typically be needed to manage those resources on behalf of the process. This involves the release of the CPU control from the process to the OS. This release is triggered by various conditions, that can usually be classified as follows:

• Explicit request: the process branches to one of the OS routines (in particular, it could explicitly request to be suspended). Appropriate steps be taken in order maintain through the branch the OS's exclusive on privileged execution mode. Typically such a branch will involve the execution of an appropriate SW interrupt instruction, so that the process yields CPU control to the OS code which provides the needed service. We shall say more about this when talking about ``kernels executing in the context of a process''.
• Hardware interrupt: an hardware event generated outside the CPU that needs be serviced asynchronously. Example: I/O interrupts from DMA or peripherals. Particularly important in this class is the clock (or ``timer'') interrupt, that allows an OS to periodically regain control of the CPU no matter what the current process is doing.
• Exceptional condition originated from ``inside'' the CPU while executing the current task (e.g. attempt to execute unallowed operations, arithmetical errors, etc.)

It is at this point important to analyze the in detail the operations involved in the above CPU release/regain events. From the point of view of an OS managing several processes, in particular, it's important to differentiate between two different scenarios:

• A process is interrupted; some OS service is performed; the process is continued thereafter.
• A process is interrupted; the OS gives control to another process.

Note carefully that the first scenario can be treated similarly to a subroutine call within one process: in order to resume correctly the process after the OS actions it's necessary that only a context switch, i.e. the saving/resuming of the processor state data, be performed before and after the interruption. The second scenario implies a process switch, which is typically a much more time-consuming sequence of operations on the OS side, since it involves the update of process tables and queues, the loading of suspended processes if no ready one are available, etc. It's consequently important for efficiency reasons that the OS be able to identify what services can be provided by a simple context switch (e.g., a memory block allocation in main memory), and which ones it's better to delay, allowing CPU access to another process.

Two interesting consequences derive from the above observation. One, leading to the distinction between processes and threads will be treated later. The second is of interest here, since it leads to understand in greater detail how the OS services are performed from a process's point of view.

b.)PROCESS TERMINATION

Processes terminate either voluntarily through an exit system call or involuntarily as the result of a signal. In either case, process termination causes a status code to be returned to the parent of the terminating process (if the parent still exists). This termination status is returned through the wait4 system call. The wait4 call permits an application to request the status of both stopped and terminated processes. The wait4 request can wait for any direct child of the parent, or it can wait selectively for a single child process or for only its children in a particular process group. Wait4 can also request statistics describing the resource utilization of a terminated child process. Finally, the wait4 interface allows a process to request status codes without blocking.

Within the kernel, a process terminates by calling the exit() routine. The exit() routine first kills off any other threads associated with the process. The termination of other threads is done as follows:

• Any thread entering the kernel from user space will thread_exit() when it traps into the kernel.
• Any thread already in the kernel and attempting to sleep will return immediately with EINTR or EAGAIN, which will force them to back out to user space, freeing resources as they go. When the thread attempts to return to user space, it will instead hit thread_exit().

The exit() routine then cleans up the process's kernel-mode execution state by doing the following:

• Canceling any pending timers
• Releasing virtual-memory resources
• Closing open descriptors
• Handling stopped or traced child processes

With the kernel-mode state reset, the process is then removed from the list of active processes—the allproc list—and is placed on the list of zombie processes pointed to by zombproc. The process state is changed to show that no thread is currently running. The exit() routine then does the following:

• Records the termination status in the p_xstat field of the process structure
• Bundles up a copy of the process's accumulated resource usage (for accounting purposes) and hangs this structure from the p_ru field of the process structure
• Notifies the deceased process's parent

Finally, after the parent has been notified, the cpu_exit() routine frees any machine-dependent process resources and arranges for a final context switch from the process.

The wait4 call works by searching a process's descendant processes for processes that have terminated. If a process in ZOMBIE state is found that matches the wait criterion, the system will copy the termination status from the deceased process. The process entry then is taken off the zombie list and is freed. Note that resources used by children of a process are accumulated only as a result of a wait4 system call. When users are trying to analyze the behavior of a long-running program, they would find it useful to be able to obtain this resource usage information before the termination of a process. Although the information is available inside the kernel and within the context of that program, there is no interface to request it outside that context until process termination.

PROCESS SCHEDULING

a.)SCHEDULING QUEUES

•Job queue – set of all processes in the system.
•Ready queue – set of all processes residing in main memory,
ready and waiting to execute.
•Device queues – set of processes waiting for an I/O device.
•Process migration between the various queues.

b.)SCHEDULERS

Operating systems may feature up to 3 distinct types of schedulers: a long-term scheduler (also known as an admission scheduler or high-level scheduler), a mid-term or medium-term scheduler and a short-term scheduler (also known as a dispatcher). The names suggest the relative frequency with which these functions are performed.

• Long-term Scheduler
• Mid-term Scheduler
• Short-term Scheduler

Long-term Scheduler

The long-term, or admission, scheduler decides which jobs or processes are to be admitted to the ready queue; that is, when an attempt is made to execute a program, its admission to the set of currently executing processes is either authorized or delayed by the long-term scheduler. Thus, this scheduler dictates what processes are to run on a system, and the degree of concurrency to be supported at any one time - ie: whether a high or low amount of processes are to be executed concurrently, and how the split between IO intensive and CPU intensive processes is to be handled. In modern OS's, this is used to make sure that real time processes get enough CPU time to finish their tasks. Without proper real time scheduling, modern GUI interfaces would seem sluggish. [Stallings, 399].
Long-term scheduling is also important in large-scale systems such as batch processing systems, computer clusters, supercomputers and render farms. In these cases, special purpose job scheduler software is typically used to assist these functions, in addition to any underlying admission scheduling support in the operating system.

Mid-term Scheduler

The mid-term scheduler, present in all systems with virtual memory, temporarily removes processes from main memory and places them on secondary memory (such as a disk drive) or vice versa. This is commonly referred to as "swapping out" or "swapping in" (also incorrectly as "paging out" or "paging in"). The mid-term scheduler may decide to swap out a process which has not been active for some time, or a process which has a low priority, or a process which is page faulting frequently, or a process which is taking up a large amount of memory in order to free up main memory for other processes, swapping the process back in later when more memory is available, or when the process has been unblocked and is no longer waiting for a resource. [Stallings, 396] [Stallings, 370]
In many systems today (those that support mapping virtual address space to secondary storage other than the swap file), the mid-term scheduler may actually perform the role of the long-term scheduler, by treating binaries as "swapped out processes" upon their execution. In this way, when a segment of the binary is required it can be swapped in on demand, or "lazy loaded". [Stallings, 394]

Short-term Scheduler

The short-term scheduler (also known as the dispatcher) decides which of the ready, in-memory processes are to be executed (allocated a CPU) next following a clock interrupt, an IO interrupt, an operating system call or another form of signal. Thus the short-term scheduler makes scheduling decisions much more frequently than the long-term or mid-term schedulers - a scheduling decision will at a minimum have to be made after every time slice, and these are very short. This scheduler can be preemptive, implying that it is capable of forcibly removing processes from a CPU when it decides to allocate that CPU to another process, or non-preemptive (also known as "voluntary" or "co-operative"), in which case the scheduler is unable to "force" processes off the CPU. [Stallings, 396].

c.)CONTEXT SWITCH

A context switch is the computing process of storing and restoring the state (context) of a CPU such that multiple processes can share a single CPU resource. The context switch is an essential feature of a multitasking operating system. Context switches are usually computationally intensive and much of the design of operating systems is to optimize the use of context switches. A context switch can mean a register context switch, a task context switch, a thread context switch, or a process context switch. What constitutes the context is determined by the processor and the operating system.

THE CONCEPT OF PROCESS

a.)PROCESS STATE

The process state consist of everything necessary to resume the process execution if it is somehow put aside temporarily. The process state consists of at least following:

• Code for the program.
• Program's static data.
• Program's dynamic data.
• Program's procedure call stack.
• Contents of general purpose registers.
• Contents of program counter (PC)
• Contents of program status word (PSW).
• Operating Systems resource in use.

A process goes through a series of discrete process states.

• New State: The process being created.
• Running State: A process is said to be running if it has the CPU, that is, process actually using the CPU at that particular instant.
• Blocked (or waiting) State: A process is said to be blocked if it is waiting for some event to happen such that as an I/O completion before it can proceed. Note that a process is unable to run until some external event happens.
• Ready State: A process is said to be ready if it use a CPU if one were available. A ready state process is runable but temporarily stopped running to let another process run.
• Terminated state: The process has finished execution.

b.)PROCESS CONTROLL BLOCK

A process in an operating system is represented by a data structure known as a process control block (PCB) or process descriptor. The PCB contains important information about the specific process including

• The current state of the process i.e., whether it is ready, running, waiting, or whatever.
• Unique identification of the process in order to track "which is which" information.
• A pointer to parent process.
• Similarly, a pointer to child process (if it exists).
• The priority of process (a part of CPU scheduling information).
• Pointers to locate memory of processes.
• A register save area.
• The processor it is running on.

The PCB is a certain store that allows the operating systems to locate key information about a process. Thus, the PCB is the data structure that defines a process to the operating systems.

c.)THREADS

Despite of the fact that a thread must execute in process, the process and its associated threads are different concept. Processes are used to group resources together and threads are the entities scheduled for execution on the CPU.A thread is a single sequence stream within in a process. Because threads have some of the properties of processes, they are sometimes called lightweight processes. In a process, threads allow multiple executions of streams. In many respect, threads are popular way to improve application through parallelism. The CPU switches rapidly back and forth among the threads giving illusion that the threads are running in parallel. Like a traditional process i.e., process with one thread, a thread can be in any of several states (Running, Blocked, Ready or Terminated). Each thread has its own stack. Since thread will generally call different procedures and thus a different execution history. This is why thread needs its own stack. An operating system that has thread facility, the basic unit of CPU utilization is a thread. A thread has or consists of a program counter (PC), a register set, and a stack space. Threads are not independent of one other like processes as a result threads shares with other threads their code section, data section, OS resources also known as task, such as open files and signals.

Quiz#3

1.)What are the major activities of an Operating System with regards to PROCESS MANAGEMENT?

Ans.
-Process creation
-Process creation and deletion
-Process suspesion and resumption
-Provision of mechanism for:-Process synchronization
-Process communication
-Deadlock handling

2.)What are the major activities of an Operating System with regards to MEMORY MANAGEMENT?

Ans.
-To improve both CPU utilization and response speed,several programs are kept in memory.
-Keep track of which parts of memory are currently being used and by whom.
-Decide which process to load when memory space becomes available.
-Allocate and Deallocate memory space as needed.




3.)What are the major activities of an Operating System with regards to SECONDARY-STORAGE MANAGEMENT?

Ans.
-Free space management
-Storage allocation
-Disk scheduling

4.)What are the major activities of an Operating System with regards to FILE MANAGEMENT?

Ans.
-File creation and deletion
-Derictory creation and deletion
-Support of primitives for manipulating files and directories
-File backup on stable storage media
-Mapping files onto secondary storage

5.)What is the purpose of the COMMAND INTERPRETER?

Ans.
It reads commands from the user or from a file of commandsand executes them, usually by
turning them into one or more systemcalls. It is usually not part of the kernel since the
command interpreteris subject to changes.

SYSTEM BOOT

In order for a computer to successfully boot, its BIOS, operating system and hardware components must all be working properly; failure of any one of these three elements will likely result in a failed boot sequence.

When the computer's power is first turned on, the CPU initializes itself, which is triggered by a series of clock ticks generated by the system clock. Part of the CPU's initialization is to look to the system's ROM BIOS for its first instruction in the startup program. The ROM BIOS stores the first instruction, which is the instruction to run the power-on self test (POST), in a predetermined memory address. POST begins by checking the BIOS chip and then tests CMOS RAM. If the POST does not detect a battery failure, it then continues to initialize the CPU, checking the inventoried hardware devices (such as the video card), secondary storage devices, such as hard drives and floppy drives, ports and other hardware devices, such as the keyboard and mouse, to ensure they are functioning properly.

Once the POST has determined that all components are functioning properly and the CPU has successfully initialized, the BIOS looks for an OS to load.

The BIOS typically looks to the CMOS chip to tell it where to find the OS, and in most PCs, the OS loads from the C drive on the hard drive even though the BIOS has the capability to load the OS from a floppy disk, CD or ZIP drive. The order of drives that the CMOS looks to in order to locate the OS is called the boot sequence, which can be changed by altering the CMOS setup. Looking to the appropriate boot drive, the BIOS will first encounter the boot record, which tells it where to find the beginning of the OS and the subsequent program file that will initialize the OS.

Once the OS initializes, the BIOS copies its files into memory and the OS basically takes over control of the boot process. Now in control, the OS performs another inventory of the system's memory and memory availability (which the BIOS already checked) and loads the device drivers that it needs to control the peripheral devices, such as a printer, scanner, optical drive, mouse and keyboard. This is the final stage in the boot process, after which the user can access the system’s applications to perform tasks.

SYSTEM GENERATION

An operational system is a combination of the z/TPF system, application programs, and people. People assign purpose to the system and use the system. The making of an operational system depends on three interrelated concepts:

- System definition: The necessary application and z/TPF system knowledge required to select the hardware configuration and related values used by thez/TPF system software.

- System initialization: The process of creating the z/TPF system tables and configuration-dependent system software.

- System restart and switchover: The procedures used by the z/TPF system software to ready the configuration for online use.

The first two items are sometimes collectively called system generation; also installing and implementing. System definition is sometimes called design. System restart is the component that uses the results of a system generation to place the system in a condition to process real-time input. The initial startup is a special case of restart and for this reason system restart is sometimes called initial program load, or IPL. System restart uses values found in tables set up during system generation and changed during the online execution of the system. A switchover implies shifting the processing load to a different central processing complex (CPC), and requires some additional procedures on the part of a system operator. A restart or switchover may be necessary either for a detected hardware failure, detected software failure, or operator option. In any event, system definition (design), initialization, restart, and switchover are related to error recovery. This provides the necessary background to use this information, which is the principal reference to be used to install the z/TPF system.

Performing a system generation requires a knowledge of the z/TPF system structure, system tables, and system conventions, a knowledge of the applications that will be programmed to run under the system, and a user's knowledge of z/OS. Knowledge of the z/TPF system, Linux, and the application are required to make intelligent decisions to accomplish the system definition of a unique z/TPF system environment. The use of z/OS and Linux is necessary because many programs used to perform system generation run under control of z/OS or Linux. Although this information does not rely on much z/OS or Linux knowledge, when the moment arrives to use the implementation information, the necessary z/OS and Linux knowledge must be acquired. You are assumed to have some knowledge of the S/370 assembly program as well as jargon associated with the z/OS and Linux operating systems. Some knowledge of C language is also helpful, because some of the programs that are used to generate the system are written in C.

System definition is a nontrivial endeavor because both z/TPF system and application knowledge is necessary. An understanding of basic data organization of the system is necessary to allocate the appropriate area of online file storage for all the programs. All z/TPF system programs and application programs that are used in the online environment are placed in file storage and reside in core memory.

An appreciation of defining a system is necessary to relate a unique z/TPF system to its environment. Clearly, no amount of information can anticipate all the variants of applications to be run under the system. However, the interrelationship of the applications, the z/TPF control program, and the corresponding data structures is of paramount importance. The initial system definition must be approached with the best available information. Usually, even this is not sufficient for an accurate definition. Through knowledge, analysis, and an understanding of system guidelines, a workable operational system can be defined and initialized. A system definition is not as insurmountable as it may first seem, because the z/TPF system includes components that allow the system programmer to change the system tables and programs, the application programs, and the physical components. In this sense, the operational system can be adapted to its environment.

The initial system generation, which requires analysis techniques and knowledge of the z/TPF system, represents the beginning of a continuous process required throughout the life of an operational system.

The terms system initialization and initialization process are used to emphasize the human activity and offline procedures required to produce programs and data to be placed on online system resident storage. The term offline procedures refers to the execution of programs, written to run under z/OS or Linux, that assist in the production of the online programs and data. (The term procedures is generally used to mean a program or collection of programs.) The goal of system initialization is to place the various levels of z/TPF system storage facilities into the condition where restart procedures may be invoked to allow online processing to begin. The restart procedures are involved with the programs that build system records used to control online processing. Many of these records are assigned values identified by the initialization process. Some important distinctions of terminology follow:

- A program in the restart procedures, called the initializer program (thez/TPF system identification is CCCTIN), uses values assigned to system records used for main (core) storage management. The initializer program is not the same thing as the initialization process. The initializer program is a portion of the restart procedures.

- A system restart begins by pressing the initial program load (IPL) key. This invokes a standard S/390 IPL sequence, which in turn invokes the z/TPF system IPL program. The IPL program loads enough of the system to main storage to permit the initializer program to allocate system tables to main storage. In a loosely coupled complex, an IPL requires the coordination of each of the CPCs in the complex; if a CPC is a multiprocessor, the IPL is performed by only one of the CPUs.

An initial restart differs from an online restart, which is shown in Figure 1. An initial restart uses input data and restart programs created in the offline environment. An online restart uses some of the same data, but the data and restart programs are accessed from online files. The basic restart procedure of loading the z/TPF core resident programs and executing the initializer program is identical for both the initial restart or the online restart. The location of the restart programs and data identifies the difference. During an initial restart, additional programs to load programs and data to system storage must be invoked. Normally, much of the data put in place during an initial restart does not need to be reloaded during an online restart. (If a reload is necessary, an initial restart is required.) The basic restart programs (such as the IPL and initializer programs) and the structure of the data that these restart programs process are identical. The location of the data is different, as well as some of the data content.

Figure 1. Initial vs. online restart

VIRTUAL MACHINE

IMPLEMENTATION

"The concept of the virtual machine is one of the most important concepts in computer science today. Emulators use virtual machines, operating systems use virtual machines (Microsoft's .NET), and programming languages use virtual machines (Perl, Java)". Read on for his review of Virtual Machine Design and Implementation in C/C++, an attempt to examine and explain virtual machines and the concepts which allow them to exist.

Virtual machines are, in effect, a software model of a whole system architecture and processor. They take in bytecode (formed of opcodes, operands, and other data) and execute it, much in the same way a real system executes code. Running these operations in software, however, gives you more security, and total control over how the system works.

Virtual machines are popular for a number of reasons. The first is that they give programmers a third compiler option. You don't have to either go the dynamic interpreted route or the static compiled route, you can compile for a virtual machine instead. Another is that virtual machines aid portability. If you compile your code for a virtual machine, you can run that binary on any system to which the virtual machine has been ported.

Few books have been written on virtual machines, with only a few Java Virtual Machine titles available. Virtual Machine Design and Implementation by Bill Blunden is therefore a landmark book for anyone with an interest in virtual machines, or even system and processor architecture as a whole.

BENEFITS

Top Ten Benefits 2008

The latest version of System Center Virtual Machine Manager incorporates all the functionality of its predecessor and brings exciting new capabilities to the management of virtual machines. Here are 10 of the most valuable benefits that Virtual Machine Manager 2008 (VMM) can provide to your organization.

- Designed for virtual machines running on Windows Server 2008 and Microsoft Hyper-V Server

Hyper-V is the next-generation hypervisor-based virtualization platform from Microsoft, which is designed to offer high performance, enhanced security, high availability, scalability, and many other improvements. VMM is designed to take full advantage of these foundational benefits through a powerful yet easy-to-use console that streamlines many of the tasks necessary to manage virtualized infrastructure. Even better, administrators can manage their traditional physical servers right alongside their virtual resources through one unified console.

- Support for Microsoft Virtual Server and VMware ESX

With this release, VMM now manages VMware ESX virtualized infrastructure in conjunction with the Virtual Center product. Now administrators running multiple virtualization platforms can rely on one tool to manage virtually everything. With its compatibility with VMware VI3 (through Virtual Center), VMM now supports features such as VMotion and can also provide VMM-specific features like Intelligent Placement to VMware servers.

- Performance and Resource Optimization (PRO)

Performance and Resource Optimization (PRO) enables the dynamic management of virtual resources though Management Packs that are PRO enabled. Utilizing the deep monitoring capabilities of System Center Operations Manager 2007, PRO enables administrators to establish remedial actions for VMM to execute if poor performance or pending hardware failures are identified in hardware, operating systems, or applications. As an open and extensible platform, PRO encourages partners to design custom management packs that promote compatibility of their products and solutions with PRO’s powerful management capabilities.

- Maximize datacenter resources through consolidation

A typical physical server in the datacenter operates at only 5 to 15 percent CPU capacity. VMM can assess and then consolidate suitable server workloads onto virtual machine host infrastructure, thus freeing up physical resources for repurposing or hardware retirement. Through physical server consolidation, continued datacenter growth is less constrained by space, electrical, and cooling requirements.

- Machine conversions are a snap!

Converting a physical machine to a virtual one can be a daunting undertaking—slow, problematic, and typically requiring you to halt the physical server. But thanks to the enhanced P2V conversion in VMM, P2V conversions will become routine. Similarly, VMM also provides a straightforward wizard that can convert VMware virtual machines to VHDs through an easy and speedy Virtual-to-Virtual (V2V) transfer process.

- Quick provisioning of new machines

In response to new server requests, a truly agile IT department delivers new servers to its business clients anywhere in the network infrastructure with a very quick turnaround. VMM enables this agility by providing IT administrators with the ability to deploy virtual machines in a fraction of the time it would take to deploy a physical server. Through one console, VMM allows administrators to manage and monitor virtual machines and hosts to ensure they are meeting the needs of the corresponding business groups.

- Intelligent Placement minimizes virtual machine guesswork in deployment

VMM does extensive data analysis on a number of factors before recommending which physical server should host a given virtual workload. This is especially critical when administrators are determining how to place several virtual workloads on the same host machine. With access to historical data—provided by Operations Manager 2007—the Intelligent Placement process is able to factor in past performance characteristics to ensure the best possible match between the virtual machine and its host hardware.

- Delegated virtual machine management for Development and Test

Virtual infrastructures are commonly used in Test and Development environments, where there is constant provisioning and tear down of virtual machines for testing purposes. This latest version of VMM features a thoroughly reworked and improved self-service Web portal, through which administrators can delegate this provisioning role to authorized users while maintaining precise control over the management of virtual machines.

- The library helps keep virtual machine components organized

To keep a data center’s virtual house in order, VMM provides a centralized library to store various virtual machine “building blocks”—off-line machines and other virtualization components. With the library’s easy-to-use structured format, IT administrators can quickly find and reuse specific components, thus remaining highly productive and responsive to new server requests and modifications.

- Windows PowerShell provides rich management and scripting environment

The entire VMM application is built on the command-line and scripting environment, Windows PowerShell. This version of VMM adds additional PowerShell commandlets and “view script” controls, which allow administrators to exploit customizing or automating operations at an unprecedented level.

EXAMPLE

In figure 92 is an example of an explicitly authorized TSAF collection involving two z/VM systems sharing global resources. The entries within each box represent the CP directory entries for each CMS virtual machine.

Figure 92. TSAF Collection with Authorized Global Resource Managers and User Programs

In figure 92, users have the following authorization:

-USERa on VMSYS1 can connect only to RES2 on VMSYS2.
-USERb on VMSYS1 can connect only to RES1 on VMSYS1.
-USERc on VMSYS2 can connect to RES1 on VMSYS1 and to RES2 on VMSYS2.
-USERd on VMSYS2 can connect only to RES2 on VMSYS2.

SYSTEM STRUCTURE

SIMPLE STRUCTURE

Any part of the system may use the functionality of the rest of
the system.
MS-DOS (user programs can call low level I/O routines)

LAYERED APPROACH

– layer n can only see the functionality that layer n-1 exports
– provides good abstraction from the lower level details
• new hardware can be added if it provides the interface required of a particular layer
– system call interface is an example of layering
– can be slow if there are too many layers

SYSTEM CALLS

PROCESS CONTROL

– create/terminate a process (including self)

FILE MANAGEMENT

Also referred to as simply a file system or filesystem. The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure.Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection.

DEVICE MANAGEMENT

Device Management is a set of technologies, protocols and standards used to allow the remote management of mobile devices, often involving updates of firmware over the air (FOTA). The network operator, handset OEM or in some cases even the end-user (usually via a web portal) can use Device Management, also known as Mobile Device Management, or MDM, to update the handset firmware/OS, install applications and fix bugs, all over the air. Thus, large numbers of devices can be managed with single commands and the end-user is freed from the requirement to take the phone to a shop or service center to refresh or update.
For companies, a Device Management system means better control and safety as well as increased efficiency, decreasing the possibility for device downtime. As the number of smart devices increases in many companies today, there is a demand for managing, controlling and updating these devices in an effective way. As mobile devices have become true computers over the years, they also force organizations to manage them properly. Without proper management and security policies, mobile devices pose threat to security: they contain lots of information, while they may easily get into wrong hands. Normally an employee would need to visit the IT / Telecom department in order to do an update on the device. With a Device Management system, that is no longer the issue. Updates can easily be done "over the air". The content on a lost or stolen device can also easily be removed by "wipe" operations. In that way sensitive documents on a lost or a stolen device do not arrive in the hands of others.

INFORMATION MAINTENANCE

– get time
– set system data (OS parameters)
– get process information (id, time used)

OPERATING SYSTEM SERVICES

Operating systems are responsible for providing essential services within a computer system:
-Initial loading of programs and transfer of programs between secondary storage and main memory
-Supervision of the input/output devices
-File management
-Protection facilities

OPERATING SYSTEM STRUCTURES

System Components

OPERATING SYSTEMS PROCESS MANAGEMENT

In operating systems, process is defined as “A program in
execution” . Process can be considered as an entity that
consists of a number of elements, including: identifier,
state, priority, program counter, memory pointer, context
data, and I/O request. The above information about a
process is usually stored in a data structure, typically called
process block. Figure 1 shows a simplified process block
[10]. Because process management involves scheduling
(CPU scheduling, I/O scheduling, and so on), state
switching, and resource management, process block is one
of the most commonly accessed data type in operating
system. Its design directly affects the efficiency of the
operating system. As a result, in most operating systems,
there is a data object that contains information about all the

current active processes. It is called process controller.
Figure 2 shows the structure of a process controller ,
which is implemented as a linked-list of process blocks.

In order to achieve high efficiency, process controller is
usually implemented as a global variable that can be
accessed by both the kernel modules and nonkernel
modules. For example, any time a new process (task) is
created, the module that created this process should be able
to access the process controller to add this new process.
Therefore, process controller – the data object that controls
the current active process – is usually implemented as a
category-5 global variable. This means, both the kernel
modules and nonkernel modules can access process
controller to change its fields and these changes can affect
the uses of process controller in kernel modules.

MAIN MEMORY MANAGEMENT

Memory management is a tricky compromise between performance (access time) and quantity (available space). We always seek the maximum available memory space but we are rarely prepared to compromise on performance. Memory management must also perform the following functions:
-allow memory sharing (for a multi-threaded system);
-allocate blocks of memory space for different tasks;
-protect the memory spaces used (e.g. prevent a user from changing a task performed by another user);
-optimise the quantity of available memory, specifically via memory expansion systems.



FILE MANAGEMENT





















Also referred to as simply a file system or filesystem. The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure.
Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection.





I/O SYSTEM MANAGEMENT

The I/O system consists of:

• A buffer-caching system
• A general device-driver interface
• Drivers for specific hardware devices

SECONDARY STORAGE MANAGEMENT

Secondary storage management is a classical feature of database management systems. It is usually supported through a set of mechanisms. These include index management, data clustering, data buffering, access path selection and query optimization.
None of these is visible to the user: they are simply performance features. However, they are so critical in terms of performance that their absence will keep the system from performing some tasks (simply because they take too much time). The important point is that they be invisible. The application programmer should not have to write code to maintain indices, to allocate disk storage, or to move data between disk and main memory. Thus, there should be a clear independence between the logical and the physical level of the system.

PROTECTION SYSTEM

Protection refers to a mechanism for controlling access by programs, processes, or users to both system and user resources.

The protection mechanism must:

• distinguish between authorized and unauthorized usage.
• specify the controls to be imposed.
• provide a means of enforcement.

COMMAND-INTERPRETER SYSTEM

A command interpreter is the part of a computer operating system that understands and executes commands that are entered interactively by a human being or from a program. In some operating systems, the command interpreter is called the shell.