CST334 - Week 8

Write what you learned this eighth week in CST 334

Topic: Persistence

Well, time has flown by, and I’m already in my final week of my operating systems class. There were no assigned readings this week, but we do need to study for the final exam. A big part of the material for the last two weeks has been on persistence in operating systems. As I mentioned last week, persistence, in the context of operating systems, refers to the ability of storage to maintain a state—meaning that if a device is unexpectedly shut off, the data remains intact and is maintained. In a sense of life, persistence also means moving forward despite difficulties. We’ve encountered challenges, whether with lab projects or understanding complex concepts, but you don’t give up when you struggle; you keep moving forward to better yourself.

CST334 - Week 7

Write what you learned this seventh week in CST 334

Topic: Persistence

This week, we covered a critical area of operating systems—persistence. The readings focused on how the operating system interacts with I/O devices, particularly highlighting DMA (Direct Memory Access) and PIO (Programmed I/O). DMA allows data transfers between devices and main memory without the CPU's direct involvement, freeing it up for other tasks. In contrast, PIO requires the CPU to handle each data transfer, which consumes CPU time and limits its ability to perform other operations simultaneously

We also discussed the role of hard disk drives and RAIDs in maintaining data persistence. Persistence refers to the ability of a storage system to retain data even when the system is powered down. Hard disk drives achieve persistence by storing data magnetically on platters, ensuring that the data remains accessible even if power is lost unexpectedly. RAIDs offer additional persistence through redundancy, protecting data from failures by storing duplicate copies across multiple disks. For example, in RAID 1, data from the first drive is mirrored, or duplicated, to the other drive. This setup ensures that if the primary drive fails, all your data is still backed up on the second drive.

CST334 - Week 6

Write what you learned this sixth week in CST 334

Topic: Semaphores

This week, we continued learning and explored the topic of semaphores and their use in synchronizing multi-threaded applications. In our lab, the goal was to become familiar with semaphores, use them for synchronization, and solve the producer-consumer problem. This was done by tracking available buffer slots and ensuring mutual exclusion using semaphores. Overall, I found the lab interesting, as it deepened my understanding of how semaphores manage shared resources in multi-threaded programs.

CST334 - Week 5

Write what you learned this fifth week in CST 334

Topic: Concurrency

This week in class, we began to learn about concurrency and managing multiple threads running concurrently within a program. The challenge with running multiple threads simultaneously is that they can potentially interfere with each other. We observed this in our lab on multi-threading, for example, when multiple threads accessed a shared variable. This interference leads to race conditions, causing the program to produce unpredictable results and making the program indeterminate.

A few strategies we explored in our reading to address this issue include using locks to protect resources, ensuring that only one thread can access the data at a time, and keeping resources separate from one another. While this approach prevents multiple threads from modifying resources while they are in use by others, there are still potential issues. For example, with spin locks, a thread may spin indefinitely if it cannot acquire the lock because it is continuously denied access to the resource, which can lead to starvation.

CST334 - Week 4

Write what you learned this fourth week in CST 334 

Topic: Memory Virtualization

This week in the course, we continued to delve further into memory virtualization and how we manage memory. In the lab, we worked with the FIFO (First-In-First-Out) page replacement strategy, a method used to manage page entries in memory. Paging is a memory management technique that divides both logical memory (virtual memory) and physical memory into fixed-size blocks called pages and frames. The logical addresses are divided into pages, which are then mapped to available frames in physical memory using a page table.

The FIFO strategy does not account for whether a page has been accessed recently or frequently. Instead, it strictly evicts the page that has been in memory the longest. On the other hand, the LRU (Least-Recently-Used) approach takes into consideration the recency of use, replacing the page that has not been accessed for the longest time. 

CST334 - Week 3

Write what you learned this third week in CST 334 

Topic: Introduction to Memory Virtualization

This week, we read about how computer memory is virtualized and separated for each process. Virtualizing memory involves both the hardware and the operating system. Virtualization makes each program believe it has its own memory space. However, many programs often share memory at the same time, and the operating system manages these processes to ensure efficiency. The three main goals of memory virtualization are as follows:

1. Transparency – Implementing memory virtualization in a way that is invisible to the program.
2. Efficiency – Improving the management of memory to enhance the system's performance.
3. Protection – Ensuring that the operating system isolates processes from one another, so one process cannot affect the memory of other processes.

This week, we also worked more with C programming and piping in Linux for our lab. Essentially, piping allows one process to direct its output to the input of another process, enabling communication between them.

CST334 - Week 2

Write what you learned this second week in CST 334 

Topic: Processes

This week we had a lot of assigned reading and learned about processes, and how they interact with the CPU. A process is essentially a program in execution, actively using the CPU to perform tasks. The program itself remains inactive until it is run as a process. We also learned about voluntary and involuntary context switches. A voluntary context switch occurs when a process willingly yields the CPU to another process, often because it’s waiting for an event, such as reading data from a disk. In contrast, an involuntary context switch happens when the operating system forcefully removes a process from the CPU, typically to redistribute resources or because the process has exceeded its allotted time.

In addition, we completed our second lab, which involved programming in C and using the fork() call to create a child process by cloning the parent process. We also worked with other system calls, such as execlp(), to replace the process image and overwrite the current execution of the program with a new one.