CSUMB Week 31 (13 August 2025 - 15 August 2025)

Write a 1 - 2 paragraph journal post, of at least 250 words, summarizing what your biggest takeaways from CST334 were, including any major challenges or topics you found particularly interesting.

     Pretty much every topic in CST 334 felt challenging. With that being said, I didn't have much of a problem when learning about a specific topic such as memory allocation, page numbers, scheduling algorithms, etc., but I had problem when trying to zoom out and see the bigger picture in how they all connect together. I've reached the end of CST 334, and I still feel a bit puzzled on how the whole operating system works. I guess that's to be expected since it is rather hard to master one subject in 10 weeks or so. On the other hand, I now have much more foundational knowledge on how CPUs operate. 

     The biggest struggle, however, wasn't the topic but rather trying to figure out how to read the C language. I had a hard time especially with the pointers on the necessity of why we used it and when it was being used. I eventually understood pointers when used with single variables, but pointers for pointers and function pointers? Now that I couldn't quite grasp. 

     On the positives, I did really enjoy learning about how CPUs operate. Topics such as concurrency, threads, locks, etc. kept me questioning myself: "who came up with this? How was this all put together in the first place?" In retrospect, it's a bit funny thinking back when my little brother would talk about CPU cores or threads when he was building his first computer. Back then I didn't know what any of that meant and I figured he was probably quite wise with computers. Now I think he probably didn't really knew what any of that meant at all in the first place.

CSUMB Week 30 (6 August 2025 - 12 August 2025)

Written below is a collection of my miscellaneous and scattered notes representing what I learned from this week:

[in regards to buses]

- In regards to I/O, there are many types of "buses"

        - Memory Bus: connects CPU with main memory

        - General I/O bus: connects high-performance device like the GPU

        - Peripheral I/O bus: connects slower devices like the mouse, keyboard, etc.

- in other words, buses are basically just types of wires that connect things to the cpu + protocols that tells devices when to talk, who the data is for, etc.

[in regards to OS-device protocol]

- so there's a concept called "polling" which is basically checking the status register continuously until a device is ready

- once it is read, it will write data to the data register

        - In a concept called PIO (programmed I/O), the CPU itself will write and transfer the register

        - Instead, there's another concept called DMA (direct memory access) where we have a separate hardware that will do the mundane task of copying data so it will free up the CPU.

        - in other words: the CPU itself is personally responsible for copying data over, but DMA is basically having another "staff" that can take over that task so the CPU can do something else.

- if not polling, we can use interrupt timer to avoid polling in order to free up the CPU to do work on other processes.

[inodes]

- inode is a number and a data structure that stores everything about a file except its name and the data content

        - it stores: creation time, last access time, last modification, file size, link count, etc.

[inode + data procedure effects on bitmap]

- mkdir() will +1 inode and +1 data

- creat() will +1 inode

- open(), write(), close() will +1 data

- link() will not change the bitmap

- unlink() will not change the bitmap OR -1 inode OR -1 inode and -1 bitmap

CSUMB Week 29 (30 July 2025 - 5 August 2025)

Written below is a collection of my miscellaneous and scattered notes representing what I learned from this week:

- synchronization primitive is a general term that encompasses all tools that help coordinate the execution of multiple threads or processes, so they don't interfere with each other

- Examples include:

        - Mutex

        - Reader-Writer lock

        - Semaphore

        - Condition variables

- condition variables are essentially flags that allow a thread to either sleep or be woken up when a certain condition becomes true. This is done to avoid phenomenon called inefficient spinning.

- we declare a condition variable by calling "pthread_cond_t"

- pthread_cond_wait() a thread will sleep when this function is called

- pthread_cond_signal() a thread will wake when this function is called

- semaphore is an object that holds an integer value. This integer value is affected by 2 main function operations:

        - sem_wait(), this will decrement the value

        - sem_post(), this will increment the value

        - the integer value serves as a counter of available permissions. 

- semaphores must first be initialized with a value. This value determines the semaphore's behavior

        - 1 means it will behave as a binary semaphore (essentially act as a mutex lock)

        - greater than 1 means it behaves like a counting semaphore (allowing N resources at once)

        - 0 means all waiters will block until sem_post() is called

- a semaphore is essentially just a more flexible form of synchronization primitive that can act as mutex or as a condition variable

- reader-writer lock is a type of lock (just like mutex is) except it allows:

        - multiple readers to hold the lock at the same time OR

        - just one writer will exclusively hold onto it