Threads in C

"dead list" that contains all stopped threads and then have a special cleanup thread that simply waits for an item to be added to the list. The cleanup thread calls pthread_join() to merge it with itself. Now your entire cleanup will be handled neatly and efficiently in a single thread.

mutexes are used to serialize access to *shared data*. Don't use them for non-shared data, and don't use them if your program's logic ensures that only one thread is accessing a particular data structure at a single time.

if you are using shared data, use mutexes for both reading and writing. Surround your read and write sections with pthread_mutex_lock() and pthread_mutex_unlock(), or use them any time a program's invariant is temporarily broken.

pthread_mutex_destroy() does not free the memory used to store the pthread_mutex_t. It's up to you to free() your own memory. Also remember that both pthread_mutex_init() and pthread_mutex_destroy() return zero on success.

pthread_mutex_lock() accepts a single pointer to a mutex to lock. If the mutex already happens to be locked, the caller will go to sleep. When the function returns, the caller will be woken up (obviously), and the caller will also now hold the lock. This call either returns zero on success.

You should always unlock a mutex that you've locked as soon as safely possible (to increase performance). And you should never unlock a mutex that you don't hold a lock for

When you call pthread_mutex_trylock() you'll attempt to lock the mutex. If the mutex is currently unlocked you'll get the lock, and this function will return zero. However, if the mutex is locked this call won't block. Rather, it will return a non-zero EBUSY error value.

pthread_cond_wait() simultaneously unlock the mutex (so that other threads can modify the linked list) and wait on the condition (so that pthread_cond_wait() will wake up when it is "signalled" by another thread). Now that the mutex is unlocked, other threads can access and modify the linked list, possibly adding items

pthread_cond_wait() call has not yet returned. Unlocking the mutex happens immediately, but waiting on the condition mycond is normally a blocking operation, meaning that our thread will go to sleep, consuming no CPU cycles until it is woken up.

This is exactly what we want to happen. Our thread is sleeping, waiting for a particular condition to become true, without performing any kind of busy polling that would waste CPU time. From our thread's perspective, it's simply waiting for the pthread_cond_wait() call to return.

Immediately after unlocking the mutex, thread 2 calls the function pthread_cond_broadcast(&mycond). By doing so, thread 2 will cause all threads waiting on the mycond condition variable to immediately wake up. This means that our first thread (which is in the middle of a pthread_cond_wait() call) will now wake up.

After thread 2 called pthread_cond_broadcast(&mymutex) you might think that thread 1's pthread_cond_wait() will immediately return. Not so! Instead, pthread_cond_wait() will perform one last operation: relock mymutex. Once pthread_cond_wait() has the lock, it will then return and allow thread 1 to continue execution.