some theory review

May 21, 2002 Serguei A. Mokhov, [email protected]

1

Some Theory Review

COMP346/5461 - Operating Systems

Revision 1.2

September 30, 2003


2

Topics

• OS– Need

– Multiprogramming vs. Uniprogramming

• I/O– Interrupts vs. Polling

– DMA

• Programs, Processes and Threads Revisited

• Synchronous vs. Asynchronous– Message Passing

– Trap and Interrupts

• Common Problems in Multiprogramming– Synchronization

– Deadlock

– Mutual exclusion, critical sections…

– Security


3

OS: The Need

• A typical example:– You have a responsibility of designing a dedicated

system to control something (water pumps, conveyor production, etc).

– Dedicated implies a single user and a single process dedicated process.

• Discussion:– Would you still include an OS into the design of such a

system? (key things: security and abstraction)


4

OS: Multiprogramming vs. Uniprogramming

• A typical problem:– There a need to have a system where throughput

(number of jobs completed within a given time) is the most important factor.

– Experiments show, however, that the context switch time is a lot more than a typical execution time of an average process in the mm-OS.

• Discussion:– Again, as a system designer, would you go with

multiprogramming or uniprogramming?


5

I/O: Interrupts vs. Polling (1)

• Polling (sync. I/O): CPU routinely checks device’s status via controller:– CPU: “Dear device driver (DD), is the device done?”– DD: “Nope”– CPU: “Dear device driver (DD), is the device done?”– DD: “Nope, not yet”– CPU: “Dear device driver (DD), is the device finally

done???? I’m kinda wasting my time waiting here!”– DD: “Patience, it almost done. A couple more

cycles…”


6

I/O: Interrupts vs. Polling (2)

• Interrupts (asynchronous I/O):• CPU: “Dear device driver, say the device to do this and that,

OK?”• DD: “Sure. [To device]: CPU wants you to do this and that.

Let us know when you’re done, k?”• Device: No prob. [starts doing I/O]• CPU: [to itself]: oh, I have so much to do! [goes and does smth

else]• Device: [busy doing I/O an finally finishes]: Hey CPU!• CPU: [suddenly interrupted by the Device] What is it?• Device: I’m done with I/O. I though you might want to

know…


7

I/O: No DMA

• Usually it’s the CPU who does the transfer of the data from a device to the memory and back:– CPU: “Hey DD! I need some data for that process. Could you arrange

some?”– DD: “Yep.” [To HDD]: “Hey HDD,CPU needs some data for that

process, do you have it?”– HDD: “Here’s some”– DD: “Oh cool, CPU, here’s some data!”– CPU: [gets the data, and places it to the memory and continues with the

process]– HDD: “Here’s some more, I forgot since last time”– DD: “OK”– CPU: “What, again data? OK…” [takes it from DD and places to the

memory of the process]


8

I/O: DMA

• CPU is more free from useless work when it has a friendly DMA (Direct Memory Access) controller:– CPU: “DD, I need that data for that process from HDD.

It should be between 0x46F46F and 0x46FFFF about this big.” [goes and does smth else]

– DD: “Hey DMA! Wake up, you heard what CPU said…”

– DMA: “Yep.” [Contacts HDD, grabs specified block of data, and puts it to the specified place]: “CPU: Me done!”


9

Programs, Processes, and Threads

• Once again, what are a program, a process and a thread?

• Which one static, dynamic?

• What does a process have (consist of)?

• How threads are different from processes?– What do they consist of?


10

Synchronous vs. Asynchronous

• Message Passing– A typical async example is email. The sender doesn’t

wait for the recipient to get it.– A sync example is a bounded buffer. Sync is needed,

so that the sender waits for the receiver to get the message or a part of it before proceeding to the next part.

– Side question: why would be advisable to have processes’ mailboxes for message passing in the kernel space? Problems (hint: size and data loss)? Solutions?


11

Synchronous vs. Asynchronous (2)

• Interrupts– System Call Interface – switch

between user and kernel mode – a syscall executes trap – a sync interrupt (which is processed in the kernel as ordinary interrupt)

– From devices – async. Why?


12

Interrupts and Trap Revisited• Neither interrupt nor trap are function calls!• Interrupt is an event, or a signal (do not confuse with

UNIX signals), notifying the system that something happened.

• Interrupts are not necessarily used to switch between processes (in scheduling), but cause a context switch.

• Trap is a software interrupt, it's synchronous, whereas an ordinary interrupt is asynchronous.

• Trap is a CPU instruction, which is invoked when a user program wants either some service from an OS (system call) or causes an error (division by zero, segmentation fault, page fault, etc.).


13

The “Big” Picture

User-running

Kernel-running

Blocked Ready

Zombieexit()

syscall() - trap

wait()

SW

HW

App

App AppApp App

User mode

Kernel mode

System Call Interface

Bus

CPU: add mult mov trap

PTRDDHDDD CDDD

Common Interface: open, close, read, write

MM

PM

DMA Ctl Mon Ctl Ptr Ctl CD Ctl

int(IRQ)

int

int Ready queue

kernel


14

Common Problems in Multiprogramming

• Synchronization (act of communication).• Mutual exclusion and critical sections (only one process at a

time executing a given section of a code, usually operating on a shared resource).

• Deadlock (two or more processes waiting for each other on some resources).

• Context switch overhead.• Security (processes must not interfere with other processes, and

unauthorized users shouldn’t be able to interfere with other users).• All the above make the system much harder to implement.• Why is multiprogramming is usually still better? (hint: CPU

utilization)


15

Basic Security

• Security != Protection

• OS Protection is needed between:– Processes of one user from others in multiuser

environment.– Processes of the same user (isolation).– OS and the users (various resource managers

and device drivers vs. application software)– Various components of the OS itself.


16

Basic Security (2)

• OS on the network:• The system has to provide CIAN:

– Confidentiality– Integrity– Availability– Authentication– Authorization– Access Control

• Hence, the compilation of the protocols.


17

Basic Security (3)• Binary privilege model is NOT enough:

– Binary in a sense: GOD vs. LAMER– I.e. root (or superuser or monitor) vs. user

• Exploiting various system vulnerabilities a user can become god.– E.g. buffer overflows in trusted / privileged (falsely)

software.– Other bugs.

• Thus, sandboxing such programs and filtering system calls and having more fine-grained roles and ACLs and permissions.


18

Next Tutorial

• Synchronization

• Semaphores

• Your questions, as usual

some theory review

Documents