CODEWITHSUNDEEP
multithreadinglinux-kerneloperating-system
laura
laura

Reputation: 389

Mapping of user level and kernel level thread

While going through OPERATING SYSTEM PRINCIPLES, 7TH ED

(By Abraham Silberschatz, Peter Baer Galvin, Greg Gagne), i encountered a

statement in Thread Scheduling Section.It is given as -:

To run on a CPU, user-level threads must ultimately be mapped to an associated kernel-level thread, although this mapping may be indirect and may use a lightweight process (LWP).

see here The first half of the statement i.e

To run on a CPU, user-level threads must ultimately be mapped to an associated kernel-level

is trying to say that When a user level thread is executed ,it will need support from kernel thread like system calls.

But i am completely stuck in other half i.e

although this mapping may be indirect and may use a lightweight process (LWP)

What does it really mean ???

Please help me out !

Upvotes: 3

Views: 2554

Answers (2)

Sumeet
Sumeet

Reputation: 8292

These days the term Light Weight Processes and threads are used interchangeably.

although this mapping may be indirect and may use a lightweight process (LWP)

I know the above statement is confusing(Notice the 2 mays). I can think only 1 thing which the above statement signifies is that:

Earlier when linux supported only user-level threads, the kernel was unaware of the fact that there are multiple user-level threads, and the way it handled these multiple threads was by associating all of them to a light weight process(which kernel sees as a single scheduling and execution unit) at kernel level.

So associating a kernel-level thread with each user-level thread is kind of direct mapping and associating a single light weight process with each user-level thread is indirect mapping.

Upvotes: 3

user3344003
user3344003

Reputation: 21607

You're reading a book that is notoriously crapola. Threads are implemented in two ways.

In the olde days (and still persists on some operating systems) there were just processes. A process consisted of an execution stream and an address space.

When languages that needed thread support (e.g., Ada—"tasks") there was a need to create libraries to implement threads. The libraries used timers to switch among the various threads within the process. This is poor man's threading. The major drawback here is that, even when you have multiple processors, all the threads of a process run on the same processor. The threads are just interleaved execution within a single process that executes on one processors.

These are sometimes called "user level threads." Some books call this the "many-to-one model."

To say

To run on a CPU, user-level threads must ultimately be mapped to an associated kernel-level thread

is highly misleading. There [usually] ARE no kernel threads in this model; just processes. Multiple threads run interleaved in a process. To call this a mapping "to an associated kernel-level thread" is misleading and overly theoretical.

This is mumbo jumbo.

although this mapping may be indirect and may use a lightweight process (LWP)

The next stage in operating system evolution here was for the operating system to support threads directly. Instead of a process being an execution stream + address-space, a process became one-or-more-threads + address-space. Instead of scheduling processes for execution, the OS schedules threads for execution.

Those are kernel threads.

Your book is making the simple complex.

Upvotes: 7

Related Questions