CGS3763: Operating System Concepts

Course Description

CGS3763 Operating System Concepts covers what happens between a program and the hardware it runs on — how processes are created and scheduled, how memory is allocated and protected, how files reach a disk, and how a system arbitrates between many programs that all believe they have the machine to themselves.

The statewide inventory records the course at Miami Dade College, the University of Central Florida and the University of West Florida.

⚠ A note on the evidence behind this guide. Of those three institutions, only the University of West Florida's catalog entry was retrievable, so the specifics below — prerequisites, level, department — are UWF's. The subject itself is one of the most standardised in the computing curriculum, which is why the outcomes and topics can be stated with reasonable confidence; but where this guide describes course mechanics rather than subject matter, read it as UWF's practice and check your own institution's catalog.

UWF places it in the Hal Marcus College of Science and Engineering, Department of Computer Science, at 3 semester hours, with the prerequisite (COP 2253 OR COP 2334 OR COP 2830) AND (CGS 2920*) — where the asterisk denotes a course that may be taken concurrently.

What the subject actually is. An operating system is a resource manager and an abstraction layer. ⚠ Its central job is a deception performed convincingly: every process is given the illusion of a private CPU and a private address space, when in reality dozens or hundreds of processes are sharing one set of cores and one physical memory. This course is the explanation of how that illusion is constructed and where it leaks.

Why it is required in nearly every computing degree. Students arrive able to write programs and generally without a model of what happens when one runs. The course supplies that model, and the payoff is diagnostic: ⚠ most performance problems, most mysterious hangs and a large share of security vulnerabilities live at the boundary this course describes. A developer who does not know the difference between a page fault and a cache miss, or why their multithreaded program is slower than the single-threaded version, is guessing.

The four pillars.

• Processes and threads — creation, states, context switching, scheduling. ⚠ Scheduling is where students first meet a genuine engineering trade-off with no correct answer: throughput against latency, fairness against priority, and the fact that optimising one degrades another.
• Concurrency and synchronisation — ⚠⚠ the hardest part of the course, without close competition. Race conditions, critical sections, mutexes, semaphores, monitors, deadlock. What makes it hard is that concurrency bugs are not reproducible: a program can be wrong and pass every test for months. Students who have only debugged deterministic code find this genuinely disorienting, and it is the reason the course insists on reasoning about correctness rather than testing for it.
• Memory management — address translation, paging, virtual memory, page replacement, thrashing. The insight most students carry away is that "memory" is not the RAM in the machine, and that the address in a pointer is not where the data is.
• Storage and file systems — file abstraction, directory structure, allocation, journalling, I/O scheduling, and the persistent theme that the gap between memory and disk speed is what most of the design exists to hide.

Concepts, not construction. ⚠ The title says Concepts, and the distinction matters when comparing institutions: a concepts course studies OS design and typically implements pieces — a scheduler simulation, a synchronisation exercise, a shell — while a "systems programming" or "OS implementation" course has students build or heavily modify a kernel. Both exist in Florida under nearby numbers. Check which one you are in before the first project lands.

Learning Outcomes

Required Outcomes

• Explain the role of an operating system as resource manager and abstraction layer, and the services it provides.
• Describe major OS architectures — monolithic, layered, microkernel, modular, virtual machine — with their trade-offs.
• Explain user mode versus kernel mode, privilege levels, and why the boundary exists.
• Trace the mechanics of a system call from library call through trap to kernel and back.
• Explain the process abstraction — process control block, state transitions, creation and termination.
• Distinguish processes from threads, and explain user-level versus kernel-level threading models.
• Explain context switching and account for its cost.
• Analyse CPU scheduling algorithms — FCFS, SJF, priority, round robin, multilevel feedback — and compute waiting and turnaround times.
• Explain starvation, aging and priority inversion.
• Identify race conditions and critical sections in concurrent code.
• Apply synchronisation primitives — locks, semaphores, condition variables, monitors — correctly.
• Solve the classical synchronisation problems: bounded buffer, readers–writers, dining philosophers.
• State the four necessary conditions for deadlock, and explain prevention, avoidance, detection and recovery.
• Apply the banker's algorithm and explain why it is rarely used in practice.
• Explain address binding, logical versus physical addresses, and the MMU.
• Explain paging — page tables, translation, the TLB, multi-level and inverted page tables.
• Explain virtual memory and demand paging, and trace the handling of a page fault.
• Compare page replacement algorithms — FIFO, optimal, LRU and approximations — and simulate them on a reference string.
• Explain thrashing, the working-set model, and locality of reference.
• Explain file system structure — the file abstraction, directories, metadata, links.
• Compare allocation methods — contiguous, linked, indexed — and free-space management.
• Explain disk scheduling and the effect of storage technology on it.
• Explain the layers of the I/O subsystem, device drivers, interrupts, DMA and buffering.
• Explain core OS protection and security mechanisms — access control, permissions, isolation.

Optional Outcomes

• Write concurrent programs using threads and synchronisation in C, C++ or Java.
• Implement a simple shell, scheduler simulator or memory allocator.
• Use POSIX system calls — fork, exec, wait, pipe, mmap — directly.
• Explain virtualisation and containers, and how they differ.
• Explain distributed operating system concepts.
• Explain real-time scheduling and its guarantees.
• Explain journalling and crash consistency in modern file systems.
• Compare the design decisions of Linux, Windows and macOS/BSD concretely.
• Explain side-channel and speculative-execution vulnerabilities at the OS boundary.

Major Topics

Required Topics

• OS overview — history, services, structure, kernel/user boundary.
• System calls and interrupts.
• Processes — the PCB, lifecycle, creation, inter-process communication.
• Threads and multithreading models.
• CPU scheduling — algorithms, criteria, multiprocessor scheduling.
• Synchronisation — critical sections, locks, semaphores, monitors.
• Classical synchronisation problems.
• Deadlock — conditions, prevention, avoidance, detection.
• Main memory — allocation, fragmentation, segmentation, paging.
• Virtual memory — demand paging, replacement, working sets, thrashing.
• File system interface and implementation.
• Mass storage and disk scheduling.
• I/O systems.
• Protection and security fundamentals.

Optional Topics

• Virtualisation, hypervisors and containers.
• Distributed systems and networked file systems.
• Real-time and embedded operating systems.
• Case studies — the Linux kernel, Windows NT architecture.
• Journalling file systems, copy-on-write, crash consistency.
• Multicore and NUMA considerations.
• Power management and mobile OS design.
• Hardware side channels — Meltdown, Spectre — and OS mitigations.

Resources & Tools

• Silberschatz, Galvin and Gagne, Operating System Concepts — ⚠ the course's namesake and the dominant text in the field, known universally as "the dinosaur book" for its covers. Comprehensive, and the source of the algorithm treatments most courses follow.
• Arpaci-Dusseau, Operating Systems: Three Easy Pieces — ⚠⚠ free, legally, from the authors at pages.cs.wisc.edu/~remzi/OSTEP/. Organised around virtualisation, concurrency and persistence, written far more readably than the standard texts, and the single best supplement for a student who finds the assigned book heavy going. Widely adopted as a primary text elsewhere.
• Tanenbaum and Bos, Modern Operating Systems — the other classic; more opinionated, strong on case studies. Tanenbaum's Operating Systems: Design and Implementation accompanies MINIX.
• Love, Linux Kernel Development and Kerrisk, The Linux Programming Interface — for the implementation-facing half; Kerrisk is the reference for POSIX system calls.
• Development environment: a Linux environment is effectively required — a virtual machine (VirtualBox, VMware, UTM), WSL2 on Windows, or a departmental server. C is the language of the subject, with gcc, gdb and make; pthreads for concurrency work.
• Observation tools that make the abstractions visible: ps, top/htop, vmstat, free, iostat, strace (⚠ strace on a running program is the fastest way to make system calls concrete), ltrace, /proc, and Windows' Process Explorer and Resource Monitor.
• Teaching kernels and simulators, where a course uses them: xv6 (MIT's teaching Unix, free and heavily documented), Pintos, MINIX 3, Nachos, and OS/161.
• Concurrency debugging: ThreadSanitizer and Helgrind (Valgrind) detect data races that testing will not — ⚠ learn one of these; it is the closest thing to a reliable tool in an unreliable domain.
• Free lecture material: MIT 6.1810 (formerly 6.828), Berkeley CS162, and Wisconsin's OSTEP course pages — all with public assignments and readings.

Career Pathways

This course is a foundation rather than a job title. Few graduates write operating systems; ⚠ nearly all of them work above one, and the ones who understand it debug problems the others escalate.

• Software developers, systems software (SOC 15-1253) — the direct destination: kernels, drivers, embedded systems, runtimes.
• Software developers, applications (SOC 15-1252) — where the material shows up as performance work, concurrency correctness and resource management.
• Site reliability and DevOps engineers (SOC 15-1244, 15-1252) — ⚠ arguably the field where this course pays off fastest: containers, cgroups, namespaces, memory limits and I/O behaviour are all direct applications of it.
• Systems administrators (SOC 15-1244) — Linux administration is applied OS concepts.
• Information security analysts (SOC 15-1212) — privilege boundaries, isolation and memory protection are the security model.
• Embedded and firmware engineers (SOC 17-2061, 15-1253) — ⚠ significant Florida demand at L3Harris, Lockheed Martin, Northrop Grumman and the Space Coast contractors, where real-time and safety-critical systems make this material non-negotiable.
• Database and cloud engineers (SOC 15-1242, 15-1244) — storage engines and cloud platforms are OS problems restated.
• Performance engineers (SOC 15-1252) — diagnosing why software is slow is largely diagnosing its interaction with the OS.
• Computer and information research scientists (SOC 15-1221) — with graduate study; systems is an active research area.

⚠ Practical note on interviews. Operating systems is one of the topics consistently examined in technical interviews at larger employers — processes versus threads, deadlock, virtual memory and mutex versus semaphore recur to the point of cliché. Retain this material rather than clearing it after the final.

Special Information

⚠ Single-source guide — what that means for you

The inventory records three institutions; one catalog was retrievable. Read the practical detail accordingly:

• The subject matter is safe. Operating systems is among the most standardised courses in computing — the ACM/IEEE computing curricula specify it, and the topic list above appears in substantially this form everywhere.
• ⚠ The mechanics are not. Prerequisites, programming language, project weight and whether the course includes kernel work vary considerably, and this guide can only state UWF's.
• Confirm with your own institution's catalog and, better, the syllabus — particularly the programming component, which is the largest source of variation.

Prerequisites — and the concurrent one

UWF requires (COP 2253 OR COP 2334 OR COP 2830) AND (CGS 2920*).

• The first block is programming — Java, C++ or another introductory sequence course. Any one satisfies it.
• ⚠ CGS 2920 carries an asterisk, meaning it may be taken concurrently — the same term, not before. Do not read a concurrent prerequisite as optional; it is required, and taking this course without registering for it will block you.
• ⚠ What the catalog does not require but the course assumes: comfort with C and with pointers, and some exposure to computer organisation — how memory, caches and interrupts work at the hardware level. Students who have taken a computer-organisation course (the CDA prefix in Florida) find this course substantially easier, because the OS is built directly on those mechanisms.
• ⚠ The most common preparation gap is C, not concepts. Students arriving from a Java- or Python-only background can follow the lectures and stall on the projects. If your background is managed languages, spend time with C and pointers before the term starts — that is the difference the course will not teach you.

Course format and workload

3 credits, 45 contact hours — lecture, three hours per week. No C or L suffix, so no scheduled laboratory; programming work is assigned outside class.

⚠ The absence of a lab suffix understates the workload. Expect 8–12 hours per week outside class in a project-heavy section — the concurrency and memory-management assignments are the ones that consume weekends.

Assessment typically includes two or three exams, several programming projects and problem sets on the scheduling and paging algorithms. ⚠ The exams reward being able to simulate an algorithm by hand — page replacement on a reference string, scheduling on a job set — which is a mechanical skill worth practising rather than reading about.

⚠ Where students actually struggle

• ⚠⚠ Concurrency, by a wide margin. The mental shift is from "what does this code do" to "what could this code do under every possible interleaving." A concurrency bug can hide behind a thousand successful runs, which invalidates the debugging strategy every student has relied on until now. Reason about the invariant; do not test until it passes.
• Virtual memory address translation. Multi-level page tables with TLBs are genuinely fiddly on paper. Draw the translation out by hand until it is automatic — exam questions are mechanical and the marks are available.
• C and pointers — see above; this is the practical blocker more often than any concept.
• Debugging concurrent code with a debugger, which perturbs the timing that produced the bug. ⚠ Learn ThreadSanitizer or Helgrind early rather than in week twelve.
• The abstraction gap. Students who have never seen what is beneath their language find the first weeks disorienting. It resolves — but running strace on a "hello world" in week one resolves it faster than any lecture.

Position in the curriculum, and articulation

⚠ This is a 3xxx upper-division course, normally taken in the junior year after the programming sequence and data structures, and it is required in essentially every computer science degree. Florida College System institutions generally do not offer it — it is taken after transfer, and an A.A. transfer student should expect it in their first upper-division year.

⚠ Prefix note, and it matters here. CGS is general computer studies — the prefix Florida uses for courses that serve more than one programme. The same subject appears under COP (computer programming) and CDA (computer design/architecture) at other institutions, and COP4610 is a common number for operating systems in Florida. Search by subject, not prefix, when checking whether a receiving programme's OS requirement is met; a transfer evaluator matching on prefix alone can miss an equivalent course.

Because this is a required course in the major with a well-defined national scope, a documented equivalent normally transfers — but keep the syllabus, since the evaluation will turn on topic coverage rather than the number.

AI Integration

Where AI assistance genuinely helps in this course:

• Explaining a mechanism a different way. Address translation, the working-set model and the semantics of a semaphore are concepts where a second explanation frequently lands when the first did not — and models are good at producing one.
• Walking an algorithm through an example. Stepping LRU through a reference string, or the banker's algorithm through an allocation state, with the reasoning shown. ⚠ Check the arithmetic — the method will usually be right and the numbers frequently are not.
• C and systems-programming syntax. fork/exec patterns, pthread setup, signal handling — boilerplate that is easy to get subtly wrong and not what the course is assessing.
• Reading unfamiliar kernel or systems code, where the idioms are dense.

⚠⚠ Where AI assistance fails badly, and this course is a particularly sharp case:

• ⚠⚠ Concurrent code. Generated synchronisation code compiles, runs, passes casual testing, and contains races. This is not an occasional failure — it is characteristic, because the training data is full of concurrent code that is also subtly wrong, and because correctness here is a property of every possible interleaving, which is not visible in the text of the program. A model producing plausible-looking lock usage is producing exactly the artefact this course exists to teach you to distrust. Verify by reasoning about the invariant, not by running it.
• Version- and platform-specific system behaviour. System call semantics, error codes and kernel behaviour differ across Linux versions, BSD and Windows; models blend them. The man page is authoritative; the model is not.
• Deadlock analysis. Asked whether a lock ordering can deadlock, models are unreliable in both directions — and the reasoning has to be yours anyway, since that reasoning is the skill.
• Projects done by generation. ⚠ The scheduler and memory-manager projects are the course. A student who generates them passes the assignment, fails the exam, and — the more consequential outcome — cannot answer the operating-systems questions that technical interviews reliably ask.

The domain connection worth noticing. ⚠ Running large models is itself an operating-systems problem — GPU memory management, scheduling inference across accelerators, paging model weights, container isolation for multi-tenant serving. The people who make AI infrastructure work are systems engineers, and this course is where that specialisation starts. It is a reasonable answer to "why am I learning this."

Academic integrity. Follow the course policy, which for programming projects is normally specific and normally stricter than students assume. Submitting generated code as your own violates every Florida institution's policy, and in this subject the practical cost of doing so arrives at the exam and the interview rather than at the grade.