Transcript Lecture4

Advanced Operating Systems - Fall 2009
Lecture 4 – January 21, 2009
Dan C. Marinescu
Email: [email protected]
Office: HEC 439 B.
Office hours: M, Wd 3 – 4:30.
1
Last, Current, Next Lecture

Last time:



Today:





Resource sharing models: multiprogramming and multitasking
Operating Systems Structures
Butler Lampson’s hints for system design
The complexity of computing and communication systems
State
Processes
Next time:

Threads
2
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?)
3
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;
4
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.
5
How

Arrange the passwordArgument such that



Try every character allowable in a password as first



its first character is the last character of a page
The next page is unassigned.
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…..
6
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.
7
Lampson’s Hints: Interfaces

Separate an implementation of an abstraction from the
use of the abstraction.



Keep it simple 


The implementation may change without affecting those who
use it.
Conceal undesirable properties; do not hide the desirable
ones.
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
8
Lampson’s Hints: Changes


Balance the desire to improve and the need to
stability.
Handle normal cases and worst cases separately.
9
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.
10
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.
11
State

Finite versus infinite state systems



State of a physical system






Hardware verification a reality.
Software verification; is it feasible?
Microscopic
Macroscopic state
State of a processor
State of a program
Snapshots - checkpointing
State of a distributed system – the role of time.
12
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
13
Process in Memory
14
Process State
15
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
16
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
17
Process Creation
18
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);
}
}
19
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

20
A tree of processes in Solaris
21
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
22
Process Control Block (PCB)







Process state
Program counter
CPU registers
CPU scheduling information
Memory-management information
Accounting information
I/O status information
23
Process Control Block (PCB)
24
Process scheduling
25
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
26
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

27
Schedulers

Long-term scheduler (job scheduler) – selects
processes to be brought into the ready queue.



Short-term scheduler (CPU scheduler) – selects
the process to be executed next.



Controls the degree of multiprogramming.
Invoked infrequently (seconds, minutes)  (may be slow)
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.
28
Medium Term Scheduler
29
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?
30
Linux O(1) scheduler

Schedules processes in constant time,
independent of the number of processes
 Minimizes jitterimportant 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.
31
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)
32
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.
33