3. Linux id of threads
● Linux uses the pid space to give ids both to threads and
processes.
● The operating system itself does know which ids belong to
threads and which to processes.
● The first threads thread id also doubles as a process id.
● This does create some confusion.
● getpid() is used to get a process id.
● gettid() is used to get a thread id.
● These may return the same value depending on whether
you are the primary thread or not.
4. pthread_t
● To complicate matters pthread has it's own
notion of thread ids.
● This is represented by an opaque pthread_t
structure.
● This structure could be gotten when creating a
thread using pthread_create() or from within the
thread using pthread_self()
5. pthread_t
● The idea is that pthread should be a cross
operating system threading API and as such
such should not expose the programmer to a
particular operating systems concept of thread
id.
● There is no simple tid hiding in that structure
and the pthread_t is not cast able to it.
● In Linux pthread_t is just an unsigned long int
(see /usr/include/bits/pthreadtypes.h).
6. gettid()
● Returns the current thread id
● Glibc does not have a wrapper for this one. Call
it using syscall(2).
● Make your wrapper efficient (cache the result
since tid never changes...).
7. CPU sets
● In order to adjust affinity for threads you will need to
be able to understand and build CPU sets.
● A CPU set is a data structure that one can pass
to/from the kernel which represents a collection of
CPUs.
● The size of CPU sets in recent Linux kernels is 1024.
● This means that unless you're running on machines
that have more than 1024 CPUs you're good to go.
9. Stopping threads - theory
● Stopping threads is one of the most difficult parts of
correct multi-threading programming.
● This sounds funny since it sounds like one should be
able to stop a thread simply by asking the operating
system to stop the thread.
● In that case one would expect the operating system
to signal the CPU that is currently running the thread
(if indeed that thread is currently running) and then
kill it's own representation of the thread.
● This is wrong!
10. Stopping threads - problems
● The idea of stopping a thread by having the operating system
kill it is wrong because of many reasons:
● On UNIX systems some of the threading issues (like allocating a
stack for the thread) are handled in user space so killing the thread
may leak resources.
● Locks acquired by the thread would possibly not be released
resulting in deadlocking other threads.
● The thread does not get a chance to release other resources
(memory, files etc) that it allocated.
●
The thread may leave data structures in unusable state because it
may be killed while manipulating them.
● Threads that are waiting on locks held by the thread that was killed
really should be notified that this thread was killed because this may
affect the way they tread data integrity.
11. Stopping threads - problem
● As a result of the above the operating system
does not support killing threads.
● The kill(1) command line and the underlying
kill(2) system call can only be used to target
processes and not threads.
● If you try to use kill(1) or kill(2) with a thread pid
you will wind up killing the entire process the
thread is a member of.
