0

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.

user2277550
  • 553
  • 7
  • 22

1 Answers1

1

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

user123
  • 2,510
  • 2
  • 6
  • 20
  • AFAIK, Linux does not support ULT. With User Level Threads, context switching and scheduling happen at the user level, supposedly. I am confused about how the stack area of multiple threads can be maintained at the user level, seemingly out of one address space. – user2277550 Jul 14 '22 at 14:49
  • You are confused. A process is created when you start an executable. The same process can have several threads. On the Linux kernel, threads are all treated the same. They have a full task_struct (PCB), a full set of registers and a stack. They share the same address space if they belong to the same process. Each thread will have their own stack and there is probably several ways to implement this. For example, you can have have several stacks at different locations of virtual memory. – user123 Jul 14 '22 at 15:25
  • User level threads refer to user mode normally enforced by the page table entries. In fact, Linux does use the user-kernel mode pattern to isolate the kernel. – user123 Jul 14 '22 at 15:27
  • I think the terminology you use is confusing actually because things don't work that way. To understand, you can find an inconsistency in what you mean by "user level threads". If the process itself is responsible to create and manage "user level threads", then the kernel is not aware of the existence of the thread. It cannot possibly schedule the thread to another core to run concurently. Your "user level thread" thus becomes exactly the same as directly calling a function for in-order execution defeating the reason for which a thread is normally created in the first place. – user123 Jul 14 '22 at 15:47
  • You probably read comon online misinformation with confusing terminology. – user123 Jul 14 '22 at 15:48
  • Hi, could you check out this old question https://stackoverflow.com/q/3225874/2277550. My doubt is exactly that. – user2277550 Aug 06 '22 at 11:01