7

I know there are :

1) User level thread - Inside the same address space of the process but with different stacks.

2) Kernel level thread - Inside the kernel memory stack (I am guessing here).

So When I create user level threads, Kernels are not aware of them [1]. So how does the kernel know, how to schedule the different user level threads in different cores. This question is regards to pthread. If pthread is user level thread, how can it run on multiple core?

Future Answer Seeker read : ( thank you to all who contributed )

1) Ziffusion's answer (below)

2) David Schwartz's answer

3) Tutorial point link

Community
  • 1
  • 1
pokche
  • 1,141
  • 12
  • 36
  • 2
    pthreads aren't (typically) user-level threads. See here: http://stackoverflow.com/questions/8639150/is-pthread-library-actually-a-user-thread-solution – Jeremy Friesner Jan 20 '16 at 00:22
  • 1
    Are those lecture notes written in Comic Sans? – paddy Jan 20 '16 at 00:22
  • 1
    It's a delusion that kernel does not know anything about user-land threads. Also, any thread can be run only on a single core at any given time. It might be rescheduled on another core next time if a kernel has any reasons to do so. – Serge Jan 20 '16 at 00:26
  • @JeremyFriesner - Yes I saw that link but did not answer the multicore part – pokche Jan 20 '16 at 00:31
  • @Serge "User-land threads" typically means "threads implemented in user-land" i.e. with user-land context switching. – user253751 Jan 20 '16 at 00:43
  • You are confusing user-level threads with user-*space* threads. – David Schwartz Jan 20 '16 at 00:47
  • 2
    @immibis according to wikipedia: "The term userland (or user space) refers to all code that runs outside the operating system's kernel" So, any code that runs in user (not kernel) context may be called either user space or userland interchangeably. Although pthreads implementations that have completely kernel-independent, in-user-software thread context switching might exist I doubt that such solutions are widely used nowadays keeping in mind that most modern kernels have support for user-space threads. – Serge Jan 20 '16 at 01:08

1 Answers1

4

So When I create user level threads, Kernels are not aware of them

This is not entirely true. At least not in the way you are thinking.

A user space thread library can choose to implement threads that do not map one to one to kernel threads - BUT - each one of these user space threads runs on a kernel thread (when it does run). This just means that the library can do it's own scheduling in user space, and decide to map the user space threads (ones it deems ready to run) to kernel threads from a pool. In this sense, the kernel is not aware of the user space threads - BUT - it is very much aware of the kernel threads that are used to run these user space threads.

The kernel manages and schedules the kernel threads. It can run them on multiple CPUs if it so decides. In doing so, it causes the user space threads mapped to such kernel threads to run on these CPUs as well.

This can be seen in many systems in fact. Threads in Java or Python, greenlets in Python, goroutines in golang - all use this mechanism.

Pthreads used to be like this too, but their implementation was changed to map each pthread to a dedicated kernel thread. But it is quite possible for a pthreads implementation to still use the user space thread model.

There is another model where user space threads can be completely a user space abstraction, which the kernel is entirely unaware of. For example, it is possible to use setcontext() and getcontext() to implement user space threads that live inside a single process.

Ziffusion
  • 8,779
  • 4
  • 29
  • 57