Josh's CSUMB Learning BLOG

  This week we discussed persistence and I/O. We reviewed the two types of i/o devices, block devices and stream devices. Block devices are like hard drives that have a fixed size of data that can be accessed randomly. Stream devices generate a stream of bytes that are not addressable; they come in a stream and are ephemeral. Each i/o device has its own hardware that is like a computer and has 3 registers. Status register is read to check the device state, command register to execute read, write or seek commands, and data register to actually transfer data. There are three ways to interact with devices: polling, interrupt-driven, and DMA. Polling put the cpu in a tight loop checking the status register and when the device is idle, executing a command and transferring data. It has the least latency. Interrupt driven uses less cpu because instead of a loop it puts the thread or process to sleep while waiting for the device. DMA uses special hardware to copy data from a device to a me...

  Josh Goldberg CST 334-40_2262 Apr 14, 2026 Journal Entry Week 6 This week we covered how to write proper sync barriers for threads to prevent a variety of locking conditions. We started by reviewing condition variables, which let a thread sleep until a signal is generated by another thread that the sleeping one should wake up. This uses pthread_cond_wait and pthread_cond_signal or pthread_cond_broadcast to wake one or all threads waiting on the CV, respectively. The Anderson-Dhalin method is a recipe to write these code patterns: 1. Design the class as usual, 2. Add locks, 3. lock/unlock around the method, 4. add CVs with names that accurately describe the condition, 5. Signal after the state changes, and 6. Add waits inside a loop. The loop is important to deal with spurious wakeups. We discussed using semaphores instead of CVs because semaphores hold a value. They are useful for different patterns with the same constructs such as locking (like with CVs), ordering and joining, a...

This week we covered concurrency using multithreaded programming with the POSIX api. Concurrency solves the problems of parallelism and avoiding i/o blocking. This is important to operating systems because it allows for better sharing of the hardware resources. Threads allow for independent execution context within a process. Each thread has its own program counter, stack, and registers, but they all share the same memory space. This gives them a lower cost to create. One thing to be careful about is critical sections of code where multiple threads need to access a shared resource. We can’t allow them to operate on that resource simultaneously or else we could have a race condition where the output depends on the timing of thread execution. When a program has different output from one run to another it is called indeterminate. To avoid this we use locks to isolate the shared data such that only one thread can access it at a time - mutual exclusion. Atomic operations are operations that...

  Josh Goldberg CST334 40_2262 Mar 30, 2026 This week we went deeper into paging and free space management. We reviewed the malloc() and free() library functions and how they manage memory allocation with a free list. The free list contains chunks that have a size and a pointer to the next free node in a linked list. Behind these functions are the mechanisms that satisfy the memory allocation policies. Splitting will split a chunk into two to right-size a chunk for an allocation request and keep the remainder fragment in the free chunk list. Coalescing is the inverse. It will merge adjacent free chunks to reduce small fragments. Each chunk has a header that indicates the next chunk, whether this chunk is free or not, and a magic number for integrity checks. Following the header is the actual chunk space to be allocated. When a free(ptr) is called with a pointer to space, it’s pointing at the free space. We find the header at ptr - sizeof(header_t). Allocator goals: correctness, spe...