For the last several months in this column, we’ve been looking at programming with Linux’s threads library, pthreads. However, we have taken for granted the work that is actually done under the covers by the pthreads libraries. So this month’s Compile Time will dissect Linux pthreads themselves to discover exactly what it is that makes them tick.
For the last several months in this column, we’ve been looking at programming with Linux’s threads library, pthreads. However, we have taken for granted the work that is actually done under the covers by the pthreads libraries. So this month’s Compile Time will dissect Linux pthreads themselves to discover exactly what it is that makes them tick.
Before we dive in and start looking at this topic though, you’ll probably find it a lot easier to follow if you are already familiar with a couple of other concepts. First, we assume that you have an understanding of the difference between code that runs in “privileged mode” (i.e., kernel space) and code that runs in “user mode” (i.e., user space). It’s also important that you understand how system calls work and how they switch between user mode and privileged mode. If you need to brush up on these topics, a good introduction can be found in the May 1999 Compile Time, located on the Web at: http://www.linux-mag.com/1999-05/compile_01.html.
There are three basic ways that threads can be implemented on a system: many-to-one, one-to-one, and many-to-many. Each method requires a different amount of support from the operating system and has its own strengths and weaknesses. The names of the methods refer to the number of threads the application ’sees’ in user space compared to the number of threads (i.e., processes) the operating system sees in kernel space.
Many-to-One
In a many-to-one implementation of threads, the threads are…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
