1. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 1 Some Theory Review COMP346/5461 - Operating Systems Revision 1.2 September 30, 2003

2. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 5 I/O: Interrupts vs. Polling (1) Polling (sync. I/O): CPU routinely checks devices 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???? Im kinda wasting my time waiting here! –DD: Patience, it almost done. A couple more cycles…

6. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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 youre 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: Im done with I/O. I though you might want to know…

7. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 7 I/O: No DMA Usually its 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: Heres some –DD: Oh cool, CPU, heres some data! –CPU: [gets the data, and places it to the memory and continues with the process] –HDD: Heres 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 10 Synchronous vs. Asynchronous Message Passing –A typical async example is email. The sender doesnt 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 13 The Big Picture User-running Kernel-running BlockedReady Zombie exit() syscall() - trap wait() SW HW App User mode Kernel mode System Call Interface Bus CPU: add mult mov trap PTRDDHDDDCDDD Common Interface: open, close, read, write MM PM DMA CtlMon CtlPtr CtlCD Ctl int (IRQ) int Ready queue kernel

14. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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 shouldnt 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 16 Basic Security (2) OS on the network: The system has to provide CIA N : –Confidentiality –Integrity –Availability –Authentication –Authorization –Access Control Hence, the compilation of the protocols.

17. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 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. May 21, 2002Serguei A. Mokhov, mokhov@cs.concordia.ca 18 Next Tutorial Synchronization Semaphores Your questions, as usual