Content tagged threads

Final thoughts. What's next?

What do you do when you need to signal state changes between threads? Condition variables are likely what you need. Futexes are general enough to be helpful here as well.

Chapter seven deals with read-write locks. They come in handy when many readers may access a resource mutated by relatively few writers.

Linux allows for assigning priorities to tasks and scheduling their execution according to various strategies. It has implications for locking, where the thread's priority may change after it has acquired a mutex. We deal with all that here.

Chapter five discusses cancelation. Threads may be canceled either synchronously or asynchronously. When they are canceled, they can call cleanup handlers. The process is quite involved and invokes some heavy Linux machinery.

Chapter four discusses detaching and joining threads, passing the return value to the parent, and dynamic initialization of data used concurrently by groups of threads.

In part three, we deal with synchronizing access to shared resources. As you know, bad things happen when multiple threads write to the same memory. We will implement basic mutexes using atomic operations on memory and futex syscalls for sleep management.

In the second chapter of the threading saga, we need to find a way to store and retrieve the pointer to the current thread by calling a function. It will be necessary for various internals and the thread-local storage. We can keep it in the Segment Register typically not used in x86_64 long mode but still taken care of during the context switch.

This is the first in a series of posts describing a threading library I built on top of Linux syscalls without Glibc. This post describes how to call syscalls, manage heap memory with custom-built malloc, and use the clone syscall to create a thread.