CST 334 - Week 5

 This week was about concurrency and threads, as well as locks—a topic related to threads. I was already familiar with threads, so this topic wasn’t too hard to understand, but I still have trouble focusing on and understanding the book. Continuing with the topic, threads are compared to processes in the book, but they are not the same. One key difference mentioned is that threads share memory, which allows a program to perform multiple actions at the same time, without waiting for one action to finish before starting another. The book explains that this makes programs more efficient. However, it also introduces potential problems—such as when multiple threads try to update the same resource at the same time. This can cause the program to behave unpredictably or produce incorrect results.

To help avoid this kind of issue, lock implementations are used. A lock ensures that only one thread runs at a time when accessing a shared resource. The thread holds the lock while it’s running, and when it finishes, it releases it so another thread can proceed. The ticket lock is one example, and it allows threads to process in a fair and orderly way. There are also spin locks, which are simpler, but they lack fairness. With spin locks, it’s possible that some threads may never get the chance to run if the same ones keep getting selected. Locks were something new for me. When I first learned about threads, I didn’t realize their order could be affected or that there were solutions like locks to fix this.

Comments

Popular posts from this blog

Module 2:

Module 4:

Module 5 - 338