Do threads (pthreads) automatically get assigned ids in posix? - multithreading

I'm not understanding the difference between creating a thread (say: pthread_t t1;) & thread id. When I tried printing the thread id using pthread_self() it gave a random number. Are threads automatically assigned an id then? How can we give a pthread an id?
The code here is for context:
#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
void * PrintHello(){
printf("Thread%d: Hello World!\n", pthread_self());
}
int main(){
pthread_t t1, t2;
pthread_create(&t1, NULL, &PrintHello, NULL);
pthread_create(&t2, NULL, &PrintHello, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
}

pthread_create creates a new thread and . A thread is a kernel resource and it is controlled using a descriptor, that is, a data structure (typically an integer) from the user point of view.
It is a bit like when you request a command on a physical/online shop and someone give you a command ID once the command is paid. This command ID is useful to probe the state of the command and request for modifications. The commend ID is not the command itself : as a user, you can only get an ID. The data structure containing the information about the commend is stored on an information system (eg. database) of the physical/online shop. For pthreads, the thread ID is like a command ID and the shop is the kernel.
When I tried printing the thread id using pthread_self() it gave a random number.
A pthread_t data structure is an opaque data type. You should not print it. If you do then the result will be undefined (platform-dependent). Here is what the documentation states:
POSIX.1 allows an implementation wide freedom in choosing the type used to represent a thread ID; for example, representation using either an arithmetic type or a structure is permitted. Therefore, variables of type pthread_t can't portably be compared using the C equality operator (==); use pthread_equal(3) instead.
Thread identifiers should be considered opaque: any attempt to use a thread ID other than in pthreads calls is nonportable and can lead to unspecified results.
Thread IDs are guaranteed to be unique only within a process. A thread ID may be reused after a terminated thread has been joined, or a detached thread has terminated.
The thread ID returned by pthread_self() is not the same thing as the kernel thread ID returned by a call to gettid(2).
If you want to print a thread ID like the one printed in top, htop, etc. then you should use the function gettid which returns a pid_t type which is an integer. Note gettid is a thread ID in the context of the Linux scheduler while pthread_self also return a thread ID, but a pthread_t in the context of pthread only meant to control/probe the state of a thread or compare its ID to others (using pthread_equal). A pthread_t type is useful to interact with threads using the pthread API : for example to wait a thread (pthread_join). A pid_t is useful to interact with the Linux kernel scheduler : for example to change the priority of a thread or its affinity to cores. More details are available in this post or this one.
Are threads automatically assigned an id then?
Yes. When a thread is created, it has an associated pthread_t value and a pid_t ones.
How can we give a pthread an id?
AFAIK, a user cannot set them. This is the job of pthread (for pthread_t) and the kernel (for pid_t).

Related

get pthread_t from thread id

I am unable to find a function to convert a thread id (pid_t) into a pthread_t which would allow me to call pthread_cancel() or pthread_kill().
Even if pthreads doesn't provide one is there a Linux specific function?
I don't think such a function exists but I would be happy to be corrected.
Background
I am well aware that it is usually preferable to have threads manage their own lifetimes via condition variables and the like.
This use is for testing purposes. I am trying to find a way to test how an application behaves when one of its threads 'dies'. So I'm really looking for a way to kill a thread. Using syscall(tgkill()) kills the process, so instead I provided a means for a tester to give the process the id of the thread to kill. I now need to turn that id into a pthread_t so that I can then:
use pthread_kill(tid,0) to check for its existence followed by
calling pthread_kill() or pthread_cancel() as appropriate.
This is probably taking testing to an unnecessary extreme. If I really want to do that some kind of mock pthreads implementation might be better.
Indeed if you really want robust isolation you are typically better off using processes rather than threads.
I don't think such a function exists but I would be happy to be corrected.
As a workaround I can create a table mapping &pthread_t to pid_t and ensure that I always invoke pthread_create() via a wrapper that adds an entry to this table. This works very well and allows me to convert an OS thread id to a pthread_t which I can then terminate using pthread_cancel(). Here is a snippet of the mechanism:
typedef void* (*threadFunc)(void*);
static void* start_thread(void* arg)
{
threadFunc threadRoutine = routine_to_start;
record_thread_start(pthread_self(),syscall(SYS_gettid));
routine_to_start = NULL; //let creating thread know its safe to continue
return threadRoutine(arg);
}
Sensible conversion requires there to be a 1:1 mapping between pthread_t and pid_t tid, which is the case with NPTL, but hasn't always been the case, and won't be the case on every pthread platform. That said...
Two options:
A) override the actual pthread_create, using LD_PRELOAD and dlsym, and keep track of each pthread_t and their corresponding pid_t there. To get the thread pid_t you can either take advantage of the pthread private headers to de-opaque the pthread_t and access the pid_t inside there, or if you want to stick to documented APIs pthread_sigqueue each pthread_t thread as it is created and have a sigaction signal handler call gettid and pass you back the thread pid_t, with appropriate synchronisation between your new pthread_create and the signal handler[1].
B) You can read the all of the thread pid_t from /proc/<process pid_t>/task/. Then use the SYS_rt_tgsigqueueinfo[2] syscall to implement a new function thread_sigqueue, a pid_t variant of pthread_sigqueue so that you can signal the pid_t thread, and from the sigaction signal handler call pthread_self passing out the value with suitable synchronization, etc.
Notes:
1 - I think it's worth writing 2 executeOnThread variants (one for pthread_t and one for pid_t style thread ids) that take a std::function<void()> (for C++), or a void(*)(void*) function pointer and void* parameter (for C), and SIGUSR1 that thread to execute the passed function in a sigaction that you also setup to perform relevant synchronization with the calling thread. It's handy to be able to use the thread-dependent APIs like pthread_self, gettid, backtrace, getrusage, etc. without devising a custom execution scheme each time.
2 - SYS_rt_tgsigqueueinfo is a low level syscall meant for implementing sigqueue/pthread_sigqueue, rather than application use, but is still a documented API, and we're using it to implement another variant of sigqueue, so fair game IMHO.

Alternate to setpriority(PRIO_PROCESS, thread_id, priority)

Given - Thread id of a thread.
Requirement - Set Linux priority of the thread id.
Constraint - Cant use setpriority()
I have tried to use below
pthread_setschedprio(pthread_t thread, int prio);
pthread_setschedparam(pthread_t thread, int policy,
const struct sched_param *param);
Both the above APIs use pthread_t as an argument. I am not able to construct (typecast) pthread_t from thread id. I understand converting this is not possible due to different types.
Is there a way to still accomplish this ?
Some aspects of the pthread_setschedprio interface are available for plain thread IDs with the sched_setparam function (declared in <thread.h>). The sched_setparam manual page says that the process is affected (which is the POSIX-mandated behavior), but on Linux, it's actually the thread of that ID.
Keep in mind that calling sched_setparam directly may break the behavior expected from PI mutexes and other synchronization primitives because the direct call does not perform the additional bookkeeping performed by the pthread_* functions.

Is there a way to link a linux's thread TID and a pthread_t "thread ID"

On linux a thread is identified by a pthread_t or a TID. I'm looking for bridges between these two kinds of thread ids:
given a pthread_t can I get it's TID ? apparently not without hacking in pthread's internals :( but i'm still asking in case someone has a clean way to do it.
given a TID (or PID), can I get a pthread_t handle to it ?
Because the term "thread id" is ambiguous in this context (and in the documentation), a bit of background:
The POSIX pthread API defines a pthread_t type, all functions that query/act on a thread use a pthread_t argument, and we can get such a handle e.g. with pthread_self(). The documentation calls these "thread ids", but here I call them handles to disambiguate, because multiple different pthread_t values may represent the same thread, hence the need for pthread_equal(pthread_t, pthread_t).
On the other hand, on linux at least, there is a concept of TIDs or thread ids. One can get the current TID with a system call: syscall(SYS_gettid). The TID has a few interesting properties such as being unique to a thread, and comparable to PIDs, which allows to easily identify the main thread, etc.
Unfortunately, there is no portable way to do so because there is no requirement for pthread_t to map to tid:
Implementations may choose to define a thread ID as a structure. This allows additional flexibility and robustness over using an int. For example, a thread ID could include a sequence number that allows detection of "dangling IDs" (copies of a thread ID that has been detached). Since the C language does not support comparison on structure types, the pthread_equal() function is provided to compare thread IDs.
Historically, prior to NPTL, pthread_t did not map 1-to-1 to tid.
You would need to use pthreads library implementation details to peek at tid. I would not recommend doing that because such code would not be portable.
For the sake of curiosity only, with glibc, pthread_t is a struct pthread *:
27 int
28 __pthread_kill (pthread_t threadid, int signo)
29 {
30 struct pthread *pd = (struct pthread *) threadid;
...
40 pid_t tid = atomic_forced_read (pd->tid);
And pthread is:
122 /* Thread descriptor data structure. */
123 struct pthread
124 {
...
166 /* Thread ID - which is also a 'is this thread descriptor (and
167 therefore stack) used' flag. */
168 pid_t tid;

C++11 difference between <thread> get_id() and native_handle()

What is the difference between C++11 functions get_id() and native_handle()?
In the test program I created they return the same int value for their threads so I have no idea what the difference is.
I'm using GCC 4.8.1 on Windows.
From this reference:
get_id returns the id of the thread
and
native_handle returns the underlying implementation-defined thread handle
The thread identifier as returned by get_id should actually be a class (std::thread::id) and not a number or other platform specific handle.
The native_handle function returns just what its name implies, a native handle that can be used by the underlying operating systems thread functions. On Windows this is typically a HANDLE as returned by CreateThread, on POSIX platforms it's typically a pthread_t as initialized by pthread_create.

use futex in user space?

I need functionality of do_futex() call in user space outside of lock/unlock context. I.e., I do not need a mutex, but the exact semantics of the kernel call do_futex.
It would seem it should be available in user space, since the intent was to minimize the number of system calls, but I can't link with it.
Or is there a syscall?
Update:
I'm currently using syscall(__NR_futex, ...) to run do_futex(). But
I have to include to get __NR_futex, which is ugly
I have to include to get FUTEX_WAIT and FUTEX_WAKE, but I still don't get EWOULDBLOCK, or the maximum number of threads for WAKE
Is there a coherent wrapper?
As it's said on http://locklessinc.com/articles/obscure_synch/:
Finally, in order to block on a kernel wait-list, we need to use the Futex system call, which unfortunately isn't exposed by linux/futex.h.
And they define their own simple wrapper:
#include <linux/futex.h>
#include <sys/syscall.h>
static long sys_futex(void *addr1, int op, int val1, struct timespec *timeout,
void *addr2, int val3) {
return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
}
futex(2) system call is probably what you are looking for.
man 2 futex
Also, on side note, man syscalls gives list of all system calls.

Resources