1/19
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai | Chat |
|---|
No analytics yet
Send a link to your students to track their progress
OS performance trade-offs for Reliability/User Experience
Saving data to disk more often (reduces data loss risk) or limiting background apps (makes the system feel more responsive). Small performance costs for better user experience or reliability.
Medical device OS vs. general-purpose OS
Medical OS requires extreme predictability and reliability. Failures or unexpected delays can be dangerous, leaving very less room for errors.
Integrating key apps directly into the OS
Advantage: tighter integration improves performance, security, and UX. Disadvantage: less flexibility, making apps harder to replace or update independently.
Non-privileged programming instructions
Examples include addition, subtraction, and reading clock. They are ordinary computations not directly accessing hardware or protected resources.
Removing the shell for a GUI-only OS
Advantage: easier for beginners and intuitive for common tasks. Disadvantage: slower or less flexible than a shell for automation.
System calls needed for a `cp` command
open source and destination files, read source, write destination, close both, and error checking for missing files.
OS in firmware vs. disk for embedded systems
Firmware is always available at startup without disk dependency, making the device more reliable and predictable.
Why process creation requires a system call
Creating a process requires OS resource allocation, process-control structure creation, and memory setup, which only the OS has privileges to do.
Monolithic vs. microkernel models
Monolithic puts most services in the kernel (faster, difficult to implement/extend). Microkernel keeps kernel small and moves services outside (easier to port/extend , performance can suffer from user/kernel communication overhead)
Inefficiency from OS component layering
When a simple operation passes through many abstraction layers, each layer adds processing overhead, slowing down operations like frequent I/O.
Mobile OS restricting background processes
Benefits: saves battery and leaves more memory/CPU for active apps. Drawbacks: background apps take longer to update/respond and tasks may not run continuously.
Memory replaced vs. retained during `exec()`
Code, data, heap, and stack are replaced by the new program. PID and open file descriptors remain intact unless marked close-on-exec.
Context switch steps during process I/O
Process blocks waiting for I/O; OS saves CPU state, chooses another ready process; when I/O completes, blocked process becomes ready and can be scheduled again.
Synchronous vs. asynchronous message passing scenarios
Synchronous is best when immediate response is needed (e.g., client-server data request). Asynchronous is best when sender keeps working (e.g., background job queue).
Fork code (Question 15) a) process count
b) printf execution
a) 3 processes total: original parent, child from the first fork(), and grandchild from the second fork().
b) Once. Only the grandchild process reaches line A.
When single-threaded outperforms multithreaded
Small tasks, sequential file processing, or heavy shared data. Thread creation, scheduling, context switching, and synchronization overhead exceed work done.
Amdahl's Law[ 1 / ((1 - P) + P/N) ] speedup for 75% parallel code (a) three processing cores
(b) six processing cores
(a) 2.0x on 3 cores; (b) 2.67x on 6 cores. Calculated using S = 1 / ((1 - P) + P/N).
Parallelism type in a multithreaded spell checker
A mix. Different threads performing different jobs is task parallelism; word-checking threads working on different words simultaneously is data parallelism.
Process creation vs. thread creation resource differences
Processes need their own address space, memory mappings, and process-management structures. Threads share the process's address space, making creation cheaper.
When multithreading yields no performance gain
When work is mostly serial, synchronization is heavy, or work is too small to justify thread overhead (e.g., one long sequence of dependent calculations).