I don’t really understand the difference between the user-level threads and kernel-level threads. This is what i know so far:
Kernel-level threads
Advantages:
- if we have multiple processors/cores we can actually run the threads simultaneously ( true parallelism because the kernels scheduler has control over the threads )
- blocking a thread ( for I/O operations for example ) don’t block all the threads
Disadvantages:
- context switch is made in kernel ( which means it’s slower than in user-space )
User-level threads
Advantages:
- Faster context-switch
- Scheduling can be planned in the application ( not by OS scheduler )
Disadvantages:
- Kernel doen’t know anything about the threads so at most the process will use one processor/core at a time.
- If one thread make a blocking call, all the threads will be be blocked again because the kernel has no knowledge about the existence of the threads, and the scheduler will give other process access to the processor/core, even though other threads in this program could run.
From what I know so far I can’t answer to this question:
How does the .text(code area) of the process modifies when a kernel-level thread is created?
My intuition says that it won’t change because the threads share the same address space, thus the .text area won’t change. Another reason I find to support this answer is that the .text area is read-only. Moreover all the others areas will remain the same(.bss, heap etc). The only one that will change is the stack.
However I want to be sure that this is the correct answer.
Note: I mainly talk about the threads on linux kernel(don’t know many stuff about windows threads)
There are 4 different types of threads that may be asked about here.
fork()syscall.clone()syscall but are managed by the kernelThe following answer assumes that “user-level” threads mentioned in the post are the pthread variety and not the “green” variety.
Edit: I think @Hristo is right and the OP is talking about “green” threads or is confusing the two.
This answer assumes you are talking about threads that you create with
pthread_create(). There are also “green” threads which are are scheduled by user-space and are unknown to the kernel. I’ll leave my answer here for posterity.User Threads == green threads
So called “green threads” are by definition threads that are handled entirely by the VM without kernel involvement.
Right.
No. As long as you using the right primitives, a blocking call will cause the thread to be put in a wait queue and another green-thread to be run.
In green-threads, they all use the same code area.
Yes.
User Threads == pthreads
With
pthread_create()“user-threads”, there is little difference between them and “kernel” threads. The linux kernel implements user-level threads as a separate kernel processes using theclone()system call.clone()creates a new process that uses the same memory space as the parent process as opposed tofork()which creates a new process with a copy of the parents memory.No, this is not correct. The kernel manages the user-level threads just like any other process in that there is context switching and the ability to schedule the various user-level threads on multiple CPUs, etc.
No, one threads can block and the other threads will continue to run. Again, this is under pthread style threads.
When a new thread is created, it inherits the memory segmentation tables of its parent. The text/code pages (and other read-only pages) are marked as read-only and the two threads share the memory for the lifetime of the threads. All read-write pages are also shared until a write is made to those sections by the new thread at which point the page is copied to another location (copy on write).
No, the heap pages, and anything else that is not marked as read-only (including the stack that you mention), will be copied as soon as they are written to. I’m not sure about .bss sections but since they are initialized at runtime, I believe they are also read-write. DATA is read-only.