Learning Journal - CST 334

 

What I learned this week in CST 334 is about the different types of lock and how they operate, some are more straight forward and others can be more complex and keep track of the CPU threads. I also learned about the decision process when it comes to utilizing locks appropriately. One must first start w/ a single lock, if its too slow then locking per bucket or node. 2^nd, for counters use approximately however many CPU it has. 3^rd, for List, hard locking is rarely faster than single lock. 4^th, for queues one should separate head & tail locks to improve throughout. Lastly, for hash tables one should use per bucket locks. With all that said, we must keep in mind that we want to start basic and work our way upwards in complexity to ensure we don’t optimize prematurely.

 

I also learned about PThread api, they also use locks known as mutexes; these functions lock and unlock the section by have a reference pointer at that certain value such as: pthread_mutex_lock(&lock); We must always check the return code and properly initialize or destroy locks. Some best practices entail keeping lock/signaling code simple, unless otherwise needed. Always keep the number of thread interactions to a minimal. Caution when passing pointers values such as stack variables to threads. Utilize the heap memory for sharing dual threads or more. This allows pthreads library to be able to build proper threads, joins, locks and condition variables. Locks can also be built in either hardware or software since they can be added to data structures to make them thread style.