My CS Online Journey

 CST334 sharpened how I think about systems by forcing me to ground every idea in code and measurement. Processes became tangible once I wrote small C programs that used fork, exec, and wait, then traced their behavior with ps and strace. Scheduling turned into a study of measurable tradeoffs rather than a list of names. I compared turnaround and response time, saw how a time slice changes interactivity in Round Robin, and learned that SJF or STCF only help when service times are predictable. Concurrency was the section that demanded the most discipline. I practiced stating invariants, identifying the true critical section, and then using mutexes, condition variables, and semaphores to preserve safety and progress. Drawing simple timelines exposed data races and order bugs that were easy to miss when reading code top to bottom. The storage and I O unit added concrete cost models. I separated seek, rotation, and transfer time, and understood why algorithms like SSTF or SCAN can help...

This week we focused on persistence and I/O in CST 334. The group project lined up well with the material, we looked at how physical interference (specifically sound in water) could disrupt hard drive performance and trigger OS-level failures. That made concepts like block devices, I/O scheduling, and file system reliability much more real. It was helpful to see how something as low-level as head misalignment could work its way up the stack to affect file systems like ext4 and applications like RocksDB. I could actually see the OS logs showing buffer I/O errors and how the system switched the filesystem to read-only when it couldn’t guarantee integrity anymore. On the content side, I got a better understanding of how the OS interfaces with devices, especially the difference between block and character devices. We also covered the performance limitations of hard drives: seek time, rotational delay, and transfer rate, and how I/O schedulers like elevator (SCAN), deadline, and CFQ try to...

This week in CST 334, I focused on semaphores and why they can be both powerful and frustrating. A semaphore is essentially a counter with two main operations: wait, which decrements the counter, and signal, which increments it. If a wait call makes the counter drop below zero, the thread pauses until another thread signals. On the surface, the idea is simple, but using them well requires keeping track of what the counter represents at every point in your program. That constant mental tracking is what makes them challenging. Unlike condition variables, semaphores can hold a signal so a thread arriving later can still move forward. This feature can be useful if planned for, or cause bugs if it is not. We explored several patterns that show how semaphores can coordinate work. The signal pattern ensures one piece of code finishes before another begins. The rendezvous pattern makes two threads meet at a specific point before either can continue. The barrier pattern expands this to multipl...