My CS Online Journey

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...

This week in CST 334, I spent time getting comfortable with concurrency and threading, specifically using pthreads in C. One major realization was seeing how concurrent programming dramatically boosts application performance and usability. A simple, relatable example is how web browsers manage tasks simultaneously. You can smoothly scroll, click, and navigate websites, while downloading files or loading content continues in the background without causing delays or freezing the interface. Practicing with pthreads helped me understand core functions such as pthread_create , pthread_join , pthread_mutex_lock , and pthread_mutex_unlock . Learning the purpose of each function parameter and seeing how they impact thread management made the concepts clearer and more intuitive. Also, I noticed that while locks are essential for maintaining data consistency, improper usage can introduce overhead and reduce performance if not handled thoughtfully. The part I found particularly valuable this week...

 This week in CST 334 I focused on making the transition from abstract concepts to concrete practice in memory management. I started by defining the terms we use most often: an address space is the set of virtual addresses a process can reference, a virtual address is the number generated by the program, and the physical address is where that data actually lives in RAM. By simulating the base and bounds scheme on paper, I saw how adding a base register to each virtual address and checking it against a bounds register enforces safety and gives the process the illusion of starting at zero. Moving on to segmentation, I drew out separate segments for code, data, and stack to understand how that approach can reduce internal fragmentation and allow different permissions on each segment. Skipping notes alone and actually writing down the address translations helped me verify my understanding and pinpoint where errors could creep in. On the hands-on side, I practiced using malloc and free...

This week in CST 334, I explored essential concepts of process management, particularly emphasizing process scheduling and its profound impact on overall system efficiency and performance. Understanding various scheduling algorithms provided valuable insights, particularly focusing on First In First Out (FIFO), Shortest Job First (SJF), and Shortest Time-to-Completion First (STCF). FIFO stood out due to its straightforward implementation and intuitive logic; however, its susceptibility to the "convoy effect," where shorter tasks are delayed behind significantly longer ones, highlighted a notable limitation. Conversely, SJF significantly improves turnaround times by prioritizing shorter tasks first, yet it comes with the impractical requirement of accurately predicting the durations of individual jobs beforehand. The Multi-Level Feedback Queue (MLFQ) scheduling algorithm was particularly fascinating, as it dynamically adapts by assigning varying priority levels based on the ob...

 Hello everyone, this week in CST 334 we started of with an engaging introduction to operating systems, giving me a better understanding of how they act as the essential link between software and hardware. I learned that an operating system manages resources, simplifies complex hardware interactions, and provides essential abstractions for users and developers. Additionally, I explored number base conversions, gaining proficiency in translating numbers between binary, decimal, and hexadecimal systems, which is crucial for low-level programming and understanding data representation at the hardware level. Furthermore, this week's lessons emphasized practical skills in programming. I became familiar with writing basic bash scripts, a helpful tool for automating repetitive tasks and executing programs in a Unix-like environment. Moreover, I gained hands-on experience in writing C programs using provided templates, allowing me to better understand the structure and syntax of C, which i...