How an OS figures out an identity of a thread calling the GetCurrentThreadId()?

Question

I'm trying to understand how an OS figures out what thread is a current one (for example, when the thread calls gettid() or GetCurrentThreadId()). Since a process address space is shared between all threads, keeping a thread id there is not an option. It must be something unique to each thread (i.e. stored in its context). If I was an OS developer, I would store it in some internal CPU register readable only in kernel mode. I googled a lot but haven't found any similar question (as if it was super obvious).

So how is it implemented in real operating systems like Linux or Windows?

Answer 1

I believe this has already been very well explained in this question: how kernel distinguishes between thread and process

If you want to find out more, you can also google for the kernel task structure and see what info is stored about each type of processes running in the user space

Answer 2

You are looking for Thread Control Block(TCB).

It is a data structure that holds information about threads.

A light reading material can be found here about the topic: https://www.cs.duke.edu/courses/fall09/cps110/slides/threads2.3.ppt

But I would recommend getting a copy of Modern Operating Systems by Andrew S. Tanenbaum if you are interested in OS.

Chapter 2 Section 2.2 Threads:

Implementing Threads in User Space - "When threads are managed in user space, each process needs its own private thread table to keep track of the threads in that process."

Implementing threads in the Kernel - "The kernel has a thread table that keeps track of all the threads in the system."

Just an edit you might also want to read "SCHEDULING". In a general manner you can say kernel decides which thread/process should be using the CPU.Thus kernel knows which thread/process made a system call. I am not going into detail because it depends on which OS we are talking about.

Answer 3

The answer to your question is entirely system specific. However, most processors know nothing about threads. They only support processes. Threads are generally implemented by created separate processes that share the same address space.

When you do a system service call to get a thread ID it is going to be implemented in the same general fashion as system service to get the process id. Imagine how a get process ID function could work in a system that does not support threads. And to keep it simple, let's assume a single processor.

You are going to have some kind of data structure to represent the current process and the kernel is going to have some means of identifying the current process (e.g. a pointer in the kernel address space to that process). On some processors there is a current task register that points to a structure defined by the processor specification. An operating system can usually add its own data to the end of this structure.

So now I want to upgrade this operating system to support threads. To that I must have a data structure that describes the thread. In that structures I have a pointer to a structure that defines the process.

Then get thread ID works the same way get process ID worked before. But now Get Process ID has an additional step that I have to translate the thread to the process to get its id (which may even be included in the thread block).