1

Advanced Operating Systems - Fall 2009Lecture 4 – January 21, 2009

Dan C. MarinescuEmail: dcm@cs.ucf.eduOffice: HEC 439 B. Office hours: M, Wd 3 – 4:30.

2

Last, Current, Next Lecture

Last time: Resource sharing models: multiprogramming and multitasking Operating Systems Structures

Today: Butler Lampson’s hints for system design The complexity of computing and communication systems State Processes

Next time: Threads

3

Lampson: Generality can lead to complexity.

System call implementation in Tenex: A system call machine instruction of an extended machine A reference to an unassigned virtual page causes a trap to

the user’s program even if caused by a system call. All arguments (including strings) to system calls passed by

reference.

The CONNECT system call access to a directory. One of its arguments a string, the password for the directory. If the password is wrong the call fails after 3 seconds (why 3s?)

4

The CONNECT system call

for i:=0 to Length(directoryPassword) do

if directoryPassword[i] ≠passwordArgument[i] then

Wait 3 seconds;

return BadPassword;

endif

endfor

connectToDirectory;

return success;

5

How to exploit this implementation to guess the password

If the password: is n characters long; a character is encoded in 8 bits;

I need in average 256n/2 trials to guess the password.

In this implementation of CONNECT in average I can guess the password in 128n trials. How? What is wrong with the implementation.

6

How

Arrange the passwordArgument such that its first character is the last character of a page The next page is unassigned.

Try every character allowable in a password as first If CONNECT returns badArgument the guess was wrong If the system reports a reference to an unassigned page the

guess is correct. Try every character allowable in a password as second…..

7

What is wrong with the implementation?

The interface provided by an ordinary memory

reference instruction in system code is complex. An improper reference is sometimes reported to the

user without the system code getting control first.

8

Lampson’s Hints: Interfaces

Separate an implementation of an abstraction from the use of the abstraction. The implementation may change without affecting those who

use it. Conceal undesirable properties; do not hide the desirable

ones.

Keep it simple Perfection is achieved not when there is no longer anything to

add, but when there is no longer anything to take away (Antoine de Saint-Exupery)

Keep basic interfaces stable

9

Lampson’s Hints: Changes

Balance the desire to improve and the need to stability.

Handle normal cases and worst cases separately.

10

The complexity of computing and communication systems

The physical nature and the physical properties of computing and communication systems must be well understood and the system design must obey the laws of physics.

The behavior of the systems is controlled by phenomena that occur at multiple scales/levels. As levels form or disintegrate, phase transitions and/or chaotic phenomena may occur.

Systems have no predefined bottom level; it is never known when a lower level phenomena will affect how the system works.

11

The complexity of computing and communication systems (cont’d)

Abstractions of the system useful for a particular aspect of the design may have unwanted consequences at another level.

A system depends on its environment for its persistence, therefore it is far from equilibrium.

The environment is man-made; the selection required by the evolution can either result in innovation, generate unintended consequences, or both.

Systems are expected to function simultaneously as individual entities and as groups of systems.

The systems are both deployed and under development at the same time.

12

State

Finite versus infinite state systems Hardware verification a reality. Software verification; is it feasible?

State of a physical system Microscopic Macroscopic state

State of a processor State of a program Snapshots - checkpointing State of a distributed system – the role of time.

13

Process

Process – a program in execution. I/O-bound process – spends more time doing I/O than

computations, many short CPU bursts CPU-bound process – spends more time doing

computations; few very long CPU bursts The code and the data manipulated by a process is in:

Memory or cache the text (code) section the data section the contents of the stack

Registers the program counter the integer and floating point

14

Process in Memory

15

Process State

16

Process Creation

Parent process create children processes, which, in turn create other processes, forming a tree of processes

Resource sharing Parent and children share all resources Children share subset of parent’s resources Parent and child share no resources

Execution Parent and children execute concurrently Parent waits until children terminate

17

Process Creation (Cont.)

Address space Child duplicate of parent Child has a program loaded into it

UNIX examples fork system call creates new process exec system call used after a fork to replace the process’

memory space with a new program

18

Process Creation

19

C Program Forking Separate Process

int main(){pid_t pid;

/* fork another process */pid = fork();if (pid < 0) { /* error occurred */

fprintf(stderr, "Fork Failed");exit(-1);

}else if (pid == 0) { /* child process */

execlp("/bin/ls", "ls", NULL);}else { /* parent process */

/* parent will wait for the child to complete */

wait (NULL);printf ("Child Complete");exit(0);

}

}

20

Examples of system processes in Solaris

Sched the scheduler pageout manages virtual memory fsflush manages the file system Init the root of all user processes Inetd responsible for networking services

telnetdeamon processes telnet commands ftpdeamon processes ftp commands

Csh command shell dtlogin process controlling a login screen Xsession process controlling an X-window session xdt_shell support for the creation of a csh for login

21

A tree of processes in Solaris

22

Process Termination

Process executes last statement and asks the operating system to delete it (exit) Output data from child to parent (via wait) Process’ resources are deallocated by operating system

Parent may terminate execution of children processes (abort) Child has exceeded allocated resources Task assigned to child is no longer required If parent is exiting

Some operating system do not allow child to continue if its parent terminates

All children terminated - cascading termination

23

Process Control Block (PCB)

Process state Program counter CPU registers CPU scheduling information Memory-management information Accounting information I/O status information

24

Process Control Block (PCB)

25

Process scheduling

26

Context Switch

When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process

Context-switch time is overhead; the system does no useful work while switching

Context switch time dependent on hardware support

27

Processes migrate among the several queues

Job queue all processes in the system Ready queue processes residing in main

memory, ready and waiting to execute Device queues processes waiting for an I/O

device

28

Schedulers

Long-term scheduler (job scheduler) – selects processes to be brought into the ready queue. Controls the degree of multiprogramming. Invoked infrequently (seconds, minutes) (may be slow)

Short-term scheduler (CPU scheduler) – selects the process to be executed next. Invoked frequently (milliseconds) (must be fast) Time slice. Relation of the time slice with the context switch time.

Medium-term scheduler – selects processes to be swapped in/out (added/removed) from the ready queue.

29

Medium Term Scheduler

30

A scheduling exercise

A system uses a scheduling strategy called Processor Sharing (PS) a hardware supported context switch occurs after each instruction and the switching overhead is zero. If a process needs T seconds to finish in the absence of

competition how much time it takes to finish when the PS strategy involves n processes?

What hardware features in addition to zero-overhead context switching are necessary to support such a scheduling strategy?

31

Linux O(1) scheduler

Schedules processes in constant time, independent of the number of processes

Minimizes jitterimportant for real time systems Efficiency:

Balance the scheduling overhead versus the time a process is allowed to run.

Interactivity requires fast response time and reduces efficiency. Difficult to accommodate both server and desktop environments.

Only one central tunable, /proc/sys/kernel/sched_granularity_ns, which can be used to tune the scheduler from 'desktop' (low latencies) to 'server' (good batching) workloads.

32

Linux O(1) scheduler (cont’d)

Fairness and starvation; a process about to starve, should get a priority boost, and/or immediate preemption.

Adaptation of an algorithm used in packet scheduling in networks.

SMP scheduling (symmetric multi-processing) Which processor to allocate? Cache considerations – schedule the same task to the same

CPU as often as possible. Eg. Intel Hyperthreading

NUMA scheduling (non-uniform memory access systems)

33

Real-time schedulers

Hard /soft deadlines Preemption Priority inversion a low priority process holds a

shared resource required by a high priority process. This causes the execution of the high priority process to be blocked until the low priority one releases the resource, effectively "inverting" the relative priorities of the two processes.

If a medium priority process, which does not require the shared resource, attempts to run in the interim, it will take precedence

over the low priority and the high priority processes.