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.