FreeExam
A closed notebook, a blank card, and a pencil on a wooden desk.

Operating systems for software engineers

20 cards

Process isolation, virtual memory, file durability, I/O readiness, and resource lifetime, with Linux-specific behavior identified where relevant.

Card 1 of 20

Front. Process Thread. What isolation difference matters when choosing processes instead of threads for untrusted work?

These cards are original study material. They are not questions from a named employer or a live hiring loop.

All 20 cards in this deck

  1. 1.Process Thread

    What isolation difference matters when choosing processes instead of threads for untrusted work?

    Processes normally have separate virtual address spaces; threads share their process memory. Process separation improves isolation but still requires appropriate OS permissions and resource boundaries.

  2. 2.Virtual Resident

    Why can a process reserve a large virtual address range without consuming that much physical RAM?

    Virtual mappings and physical resident pages are different. Pages may be allocated on demand, file-backed, shared, or not resident; inspect both address-space and resident-memory metrics.

  3. 3.Page Fault

    Does a page fault necessarily mean reading from disk?

    No. Minor faults can establish mappings or allocate pages already available in memory. Major faults require storage I/O; fault type and rate matter for diagnosis.

  4. 4.Cow Fork

    Why can Linux fork initially use less memory than copying every page into a new process?

    Copy-on-write lets parent and child share physical pages until writes require private copies. A write-heavy child can still create a large memory increase.

  5. 5.Fork Threads

    Why is calling complex library code after fork in a multithreaded POSIX process risky before exec?

    Only the calling thread survives in the child, while inherited synchronization state may reflect vanished threads. Follow the restricted safe operations and prefer supported process-spawning APIs.

  6. 6.Exec

    Does exec create another process with a new PID?

    A successful exec replaces the current process image. Process creation and program replacement are separate operations, often composed by a launcher.

  7. 7.Zombie

    Why can a terminated child remain visible as a zombie process?

    Its exit status has not been collected by a parent or appropriate reaper. It is not executing application code, but unreaped children still consume process-table resources.

  8. 8.System Call

    Why is a system call different from an ordinary function call?

    It crosses into the kernel to request privileged services, with validation and transition overhead. A library function may wrap a syscall, perform user-space work, or do both.

  9. 9.Context Switch

    Why can adding more threads reduce CPU-bound throughput?

    Scheduling and context switches add overhead, and cache locality or contention can worsen. Match useful parallelism to available resources and profile the actual workload.

  10. 10.Page Cache

    Why can rereading a file be much faster without any application-level cache?

    The OS page cache can serve the contents from memory. Benchmark warm and cold behavior separately when storage performance matters.

  11. 11.Write Durable

    Does a successful buffered write establish that data will survive power loss?

    Not by itself. Data may remain in memory or volatile caches; use the required synchronization protocol and check its result under the filesystem and storage guarantees.

  12. 12.Directory Sync

    Why can creating and fsyncing a file still leave a durability gap on Linux?

    The directory entry may not be durable. A durable creation or rename protocol may also require syncing the containing directory, with filesystem-specific guarantees understood.

  13. 13.Atomic Replace

    How can a file update avoid exposing a half-written configuration to readers?

    Write and validate a temporary file in the appropriate filesystem, then atomically rename it over the destination. Add the required file and directory synchronization when crash durability matters.

  14. 14.Partial Write

    Why must low-level write code handle a return value smaller than the requested byte count?

    A write can complete partially. Advance by the actual count and handle retries, interruptions, and errors without duplicating already-written bytes.

  15. 15.Partial Read

    Why does one successful read not guarantee a whole application record was obtained?

    The available bytes can be shorter than the logical record. Maintain framing state and continue reading until completion, EOF, or a defined error.

  16. 16.Nonblocking

    What does EAGAIN from a nonblocking socket usually tell the caller?

    The requested operation cannot proceed immediately. Wait for readiness or retry through the event loop instead of treating it as EOF or spinning continuously.

  17. 17.Edge Trigger

    Why should edge-triggered epoll handlers generally drain a nonblocking socket until EAGAIN?

    Unread data can remain without another readiness edge to wake the handler. A partial read followed by waiting can stall the protocol.

  18. 18.Readiness Completion

    Does an I/O readiness notification mean the entire requested transfer has completed?

    No. It indicates an operation may proceed without blocking under the API's semantics. The caller still performs I/O and handles partial progress or changed conditions.

  19. 19.Shared Description

    Why can file offsets interact after descriptors are duplicated or inherited across fork?

    They can refer to the same open file description and share its offset. Use positional I/O or explicit coordination when independent offsets are required.

  20. 20.Monotonic Time

    Why should elapsed timeout calculations use a monotonic clock rather than wall-clock time?

    Wall time can jump due to synchronization or administrative changes. A monotonic clock supports duration measurement without interpreting a clock correction as elapsed work.