Posts

Showing posts from December, 2025

CST-334 Week 6

 This week I learned more about conditional variables, semaphores, and how to write code using semaphores. One of the solutions we came up with was the polling solution. In this case, we want to occasionally read from the shared resource. An example of this could look something like: static int some_value = 0; void* read(void* thread) {     while (1) {          sleep(1);          some_value = get_value();     } } void* api(void* thread){ while (1) {      if (some_vaue != old_value) {          old_value = some_value;     } } } In this example, the shared resource (some_value) is being constantly read inside our loop. This ensures that we can run some condition whenever the value store inside our variable changes. However, this introduces some problems. This solution is inefficient as it is constantly running to check to the value stored inside some_value, caus...

CST-334 Week 5

 This week, I learned the benefits of concurrency, the C pthreads API, and how locks are used to protect programs from race conditions. Concurrency is beneficial as it is a useful programming abstracting, increases responsiveness, and it can leverage multicore machines and GPUs. On the other hand, concurrency can introduce bugs related to concurrency, and it can cause programs to be non-deterministic. A program is not deterministic when the output of the program is not expected and changed each time it is ran. This is commonly caused by race conditions. A race condition arises when multiple threads of execution enter the critical section (a shared resource) at roughly the same time. The threads will attempt to update the shared data structure and as the schedular will be making the decision on which thread will be run, the output if the program will become undesirable. Programs can avoid these problems by having threads use some kind of mutual exclusion primitive, which will guaran...