Week 5

 Week 5 (7/23-7/29)

This week, I learned in OS that concurrency means letting different parts of a program make progress “together.” I also learned that threads are light‑weight units of execution inside a process, which share memory but each has its own stack and registers. For example, two threads updating a shared counter can cause problems if they both do counter = counter + 1 at the same time.

I also learned that a race condition happens when threads access shared data without coordination, and the result depends on timing. I learned that a critical section is the code that touches shared data, and that a mutex lock ensures only one thread enters at a time. I learned that locks rely on atomic instructions like test‑and‑set to flip a flag in one step without interference.

Another thing I learned about the pthreads API: pthread_create lets me start a thread, pthread_join waits for it to finish, pthread_mutex_lock and pthread_mutex_unlock guard critical sections, and pthread_cond_wait and pthread_cond_signal let threads sleep and wake up based on conditions.

I also learned that I can make a simple counter safe by putting a mutex inside a struct and locking it around increment and get operations. The coarse‑grained locks are easy to write but slow down all threads, while fine‑grained locks let more threads work in parallel but are harder to code.

I finally learned that concurrency helps in real programs like browsers, where one thread loads images while I type in another. I learned that balancing safety and speed means choosing the right locking level for your data structures.