user2277550
user2277550

Reputation: 619

How do user level threads work at the level of the stack?

With KLT, each thread gets its own stack, right? And those details are maintained in a distinct PCB for each block and the different Page Tables, right? How would this apply for user level threads. Do all the threads in ULT have different stacks? If so how is it implemented?

Edit: I have since figured out that this exact question has been asked here more than 10 years ago. Unfortunately, it hasn't been answered adequately there either.

Upvotes: 1

Views: 385

Answers (1)

user123
user123

Reputation: 2884

On the Linux kernel, you'll see kernel threads around when the bottom half of an interrupt handler wasn't completed and preempted to another thread. For example, an interrupt occurs, the top half of the interrupt handler runs with interrupts disabled and then adds the bottom half to the queue of threads (in reality, it is more complex than that). This creates kernel threads. Kernel threads are given high priority so they run fast because, most likely, a user thread is waiting for their completion.

Kernel threads have their own stack which are created when creating them in the top half of an interrupt handler (when a kernel thread is created, its stack is created). As far as I know, each core has one interrupt stack for servicing interrupts. Kernel threads have their own task_struct but without an address space. Most likely, they are basically a driver's servicing function which is supposed to do some work on behalf of a device that was queried by a user mode thread. For example, let's say thread A makes a syscall to read from disk. The driver used for that disk will write some registers of the hard-disk controller to start a DMA operation from the disk. When the operation is done, the controller triggers an interrupt. During execution of the top half, the interrupt stack is used and further interrupts are disabled. The top half creates a new kernel thread which is added to the queue of ready threads with a high priority. Eventually, that kernel thread runs (with its own task_struct and stack) and finishes. When it finishes, it will place the user mode thread on behalf of which this operation was done back in the ready queue.

With the Linux kernel, user threads all have 2 stacks: one for their user mode operations and one for their kernel mode operations (during a syscall). Each user mode stack is given a fixed size (in virtual memory). Since you seem to have some misconceptions, you can read some of my answers for more details:

Process of State

What is paging exactly? OSDEV

Understanding how operating systems store/retrieve IO device input

Upvotes: 1

Related Questions