Midterm 1 Flashcards
What are they key roles of an operating system?
- Hides complexity of underlying hardware
- Manages hardware on behalf of applications
- Provides isolation & protection
- Directly has privileged access to underlying hardware
What are the differences between OS: Abstractions, Mechanisms, and Policies?
Abstractions: Hiding of the hardware complexity into a simple interface. Eg, process, thread, file, socket, memory page
Mechanisms: How to perform an action on an abstraction. Create/Schedule or thread or process, open, write, allocate
Policies: Defined behavior - what should be done. Eg, LRU, earliest deadline first (EDF) , Least Frequently Used (LFU), eg, max # of sockets process has access to
Example:
Abstraction: Memory
Mechanism: Allocate, map to a process
Policies: LRU
What is the principle of separation of mechanism and policy mean?
A mechanism should be able to employ and support a range of policies. Understand the common case then pick a specific policy that makes sense and can be supported given underlying mechanisms and abstractions operating system supports.
What does the principle optimize for the common case mean?
Find the most common case that the application is likely to encounter and optimize for that case. Don’t sacrifice common case performance to improve an edge case.
What happens during a user-kernel mode crossing?
- Privilege Bit is set
- trap occurs and OS decides if it should execute system call
- System calls gets executed (or OS decides it won’t execute request and terminates program)
- [Probably put the results somewhere]
- Privilige Bit is cleared
- control returns to user process
What are some of the reasons why user-kernel mode crossing happens?
Whenever a user needs access to a piece of the underlying hardware (system call):
- Open a file
- Send data on a socket
- Fork a process
What is a system call?
A request to access hardware [or likely a hardware abstraction] on the behalf of a user-level process.
Does user-level mode have access to hardware?
No - hardware is only accessible through kernel-level calls.
Contrast the design decisions and performance tradeoffs among monolithic, modular and microkernel-based OS designs.
Monolithic:
* Every service that could be required is part of the operating system (eg, multiple file system types)
+ Everything there!
+ inlining, compile time optimization
- customization, portability, manageability (HUGE), memory footprint, performance
Modular (more commonly used):
* Includes the most basic services and APIs, but you can add specific services (schedulers, FS’s, etc)
* Each module programs to the appropriate interface so it can be swapped out
+ maintainability, smaller footprint, less resource needs
- indirection can impact performance (b/c you must go through an interface)
- maintenance can still be an issue
Micro-kernel:
* Only require most basic primitives at OS level
* IPC, Address space, threads
* All other software components (DB, FS, Device Drivers) run outside kernel in user-mode.
* Requires lots of IPC (since most of it is implemented at user level)
+ size, verifiability
- portability, complexity of software dev
- cost of user/kernel crossing
Describe the states in a lifetime of a process?
New: Allocate/init PCB and resources
Ready: Ready to start executing until scheduled dispatched to CPU
Running: Actively Running on CPU
Waiting: Waiting for I/O or event completion
Terminated: Exit w/ exit code
New -> Ready -> Running Running -> Ready Running -> Terminated Running -> Waiting Waiting -> Ready
Describe the lifetime of a thread?
Runnable, active, sleeping, stopped, zombie
Runnable -> Stopped Runnable -> Active Active -> Runnable Active -> Zombie (DONE) Active -> Stopped Active -> Sleeping Sleeping -> Runnable Sleeping -> Stopped Stopped -> Runnable
Describe all the steps which take place for a process to transition form a waiting (blocked) state to a running (executing on the CPU) state.
Blocked (wait for I/O event to complete) -> Ready State (waiting to be scheduled) -> eventually running
What are the pros-and-cons of message-based vs. shared-memory-based IPC.
Message Based:
* Establish communication channel (such as a shared buffer)
* Then they can send/receive messages across the channel
+ OS Manages (same standard system calls)
+ Lower setup costs than shared memory, but a per use cost
- Overheads (every msg is copied from user space into kernel memory then back into memory of user process)
Shared Memory IPC:
* OS establishes shared memory and maps it into each process’ address space
* Processes can read/write to that memory like normal
+ OS is out of the way!
- Re-Implement code, more error prone
- Setup is expensive, so best if you can amortize cost of setup across large number of messages
What are benefits of multithreading?
- Parallelization (If multiple CPUs)
- Specialization (cache locality, hot cache)
- [MORE?]
Describe the boss-worked multithreading pattern.
You have a single ‘boss’ thread that sends jobs to the ‘worker’ threads. The boss often puts work in a queue and then signals to the workers that there is work to be done. The workers will take work off the queue and perform the appropriate tasks.
Describe the pipelined multithreading pattern.
There is one or more threads for each stage of a pipeline. After work completes from one stage, it moves onto the next.
Generally limited by the slowest stage of the pipeline. Best if the pipeline stages are equal in processing time.
What are mutexes?
Mutual Exclusion - A ‘lock’ that only allows a single thread to hold it. If the mutex is held by another thread and someone tries to acquire this mutex, they are put in a queue.
What’s a simple way to prevent deadlocks? Why?
To maintain a global lock order for all mutexes. This ensures that two threads aren’t holding the lock which the other is waiting for.
Can you explain the relationship among kernel vs. user-level threads?
1:1 -
* each user level thread has a kernel level thread associated with it. Pretty much everything is up to the kernel-level manager.
+ OS sees/understands threads, synch, blocking, etc
- Must go to OS for all operations
- OS may have limits on policies, thread #
- portability
M:1 -
* All user level threads in process mapped to a single kernel level thread. Pretty much everything is up to the thread level manager.
+ totally portable; doesn’t depend on OS limits and policies in kernel
- OS has no insights into application needs
- OS may block entire process is one user level thread blocks on I/O
M:N - * Some can be M:1 or 1:1, etc. \+ can be best of both worlds \+ can have bound or unbound threads - requires coordination between user and kernel level thread managers
Can you explain why some of the mechanisms described in the Solaris papers (for configuring the degree concurrency, for signaling, the use of LWP…) are not used or necessary in the current threads model in Linux?
- Modern Linux uses 1:1 model, kernel sees info for each ULT
- Setting concurrency not really necessary b/c of 1:1 model. Kernel concurrency is always equal to ULT concurrency.
- Kernel Traps are cheaper
- Changing kernel level signal masks isn’t such a big deal
- No real limit on # of threads because of larger amount of memory supported today, large range of IDs, etc
What’s an interrupt? handler?
A hardware event that tells the OS something has happened. The handler is the function that is called when such an event occurs.
What’s the potential issue if a interrupt or signal handler needs to lock a mutex? What’s the workaround described in the Solaris papers?
The process that was interrupted could already have a lock on the mutex needed in the handler. Since the interrupted thread had the lock and is now in the handler routine, it will block forever on the mutex.
Solutions:
- Spawn a separate thread to handle the interrupt.
- Disable appropriate signal handlers prior to acquiring the mutex, then re-enable them once the lock is released.
Contrast the pros-and-cons of a multithreaded (MT) and multiprocess (MP) implementation of a webserver, as described in the Flash paper.
MP:
+ More simple to implement b/c lack of synchronization
- More costly context switches
- Larger memory footprint
MT: \+ Smaller memory footprint \+ faster context switching - Must support synchronization - kernel library must support MT
What are the benefits of the event-based model described in the Flash paper over MT and MP? What are the limitations? Would you convert the AMPED model into a AMTED (async multi-threaded event-driven)? How do you think ab AMTED version of Flash would compare to the AMPED version of Flash?
Benefits:
+ Single thread of execution that is able to do work even after blocking I/O calls are made
+ Small memory footprint since there is only one thread of execution
+ No synchronization to worry about
Limitations:
- Not necessarily applicable to all software problems
- Some additional complexities w/ event routing in multi-cpu systems
Yes, I would make it a MT library today. I think MT would be a little better because there would be smaller context switching costs and possibly better cache locality since everything is in the same virtual address space.
In MT/MP, each thread/process must perform the full request, which leads to a larger memory footprint
There are several sets of experimental results from the Flash paper discussed in the lesson. Do you understand the purpose of each set of experiments (what was the question they wanted to answer)? Do you understand why the experiment was structured in a particular why (why they chose the variables to be varied, the workload parameters, the measured metric…).
NOT DONE