Learning to Think In Code

This week’s module was all about concurrency, threads, locks and also how locks can be a part of real data structure. Our main focus of the discussion was: basics of concurrency, the Thread API, Locks, and Lock-Based Data Structures. When I first read the four readings, I found it really difficult to see how all of them were connected but later I understood very well that each one is built upon the previous one. The concept of concurrency presented a single physical CPU being capable of acting like many virtual CPUs which, in turn, allows for the running of multiple threads in a program simultaneously. I got the concept that a thread is something like a mini-process but the difference is that it shares the same address space with other threads. That much was clear to me but I needed to go over the part regarding context switching between threads once again since I was not completely sure about how the registers for each thread are saved and restored. The Thread API chapter helped clear...

This week’s module covered a lot about how memory virtualization actually works, and honestly, it tied together a lot of things that were confusing before. The big topics were free-space management, paging, swapping, and translation lookaside buffers, TLB’s. Even though these ideas are all different, I started noticing how they connect to each other as part of a bigger system. Free-space management made the most sense right away because the examples clearly showed how fragmentation can mess everything up. It also helped explain why paging uses fixed-size units. Then we moved into TLBs, and that was one of my “aha” moments. Thinking of a TLB as basically a super fast “cheat sheet” that saves recent translations made the whole idea of speeding up memory access feel a lot more real. Multi-level paging was one of the topics I had to reread a couple times. The part that tripped me up was how page tables get so massive that you literally can’t store them as one giant table. Once I realized m...

This week’s module focused heavily on memory virtualization, and honestly, this has been the first week where all the topics felt like they finally connected into one big picture. We covered address spaces, the C memory API, address translation, base-and-bounds, segmentation, and paging. At first, each of these topics felt separate, but the deeper I got into the readings and the PA3 instructions, the more I started seeing how they all fit together under the idea of how the OS makes memory feel simple even though the hardware underneath is anything but. One of the clearest ideas this week was the concept of an address space. I always understood virtual vs. physical memory at a high level, but reading OSTEP 13 made it click that an address space is basically the illusion the OS gives each process, its own clean slate, even though everything is ultimately sharing the same physical RAM. That idea tied directly into the C Memory API, because malloc, free, and even pointers all rely on the O...

 During this week's class, the operating system's capability of managing multiple programs simultaneously was the main point of our discussion. The key point was the process concept, which can simply be defined as an executing program. I was not aware of the number of programs that my computer was "running" simultaneously, and thus it was fun to find out that the OS creates the illusion of having several CPUs through the continuous process switching. Physically, there may exist only one CPU, however, the impression is that everything is happening at the same time. The Process API was also a topic of discussion, mainly the fork(), exec(), and wait() functions. The fork() function, to be honest, was the most confusing to me in the beginning, as it creates a duplicate of the program and the parent and child process go on executing from the same point. This concept was a bit difficult for me to comprehend but when I saw examples, it became clearer. On the contrary, exec()...