What exactly is the lwp and threads in solaris

multithreadingsolaristhread

The book "Solaris Internals" says

Solaris executes kernel threads for kernel-related tasks, such as interrupt handling, memory page management, device drivers, etc. For user-process execution, kernel threads have a corresponding LWP; these kernel threads are scheduled for execution by the kernel on behalf of the user processes

I am a little confused about the words and below is my understanding

In solaris, the "real thread" is the "kernel thread". The kernel threads can execute kernel-related tasks and user-related tasks. When execute user-related tasks, the kernel thread needs a data structure called LWP to provide the environment.
So, the user thread and LWP are not the execution unit or thread at all. They are just data structres in the system. The user thread is just the user task needed to be executed which includes the user data and code. The LWP is the kernel data structure providing the kernel infomation. The real execution unit or flow is kernel thread.

Provided my understanding is correct, in the early solaris where two-level thread model exists, many user threads can be bound to one lwp which means that in the underlying implementation of solaris the "many user thread" are really one thread(kernel thread) to the kernel or CPU and the only kernel thread executes the tasks in each user thread in turn. If the user thread is unbound it can not be executed.

Am I right?

Best Answer

Kernel thread is the fundamental entity scheduled on the system CPU which is very light.

Kernel threads have a one-to-one mapping with an LWP. The thread-library schedules a user thread onto an LWP. sources:

Related Solutions

Understanding Linux Perf sched-switch and context-switches

I know this question is pretty old (Feb 16) but here a response in case it helps someone else. The problem is that you've entered the '-F 999' indicating that you want to sample the events at a frequency of 999 times a second. For 'trace' events, you don't generally want to do sampling. For instance, when I select sched:sched_switch, I want to see every context switch. If you enter -F 999 then you will get a sampling of the context switches... If you look at the output of your 'perf record' cmd with something like:

perf script --verbose -I --header -i perf.dat -F comm,pid,tid,cpu,time,period,event,trace,ip,sym,dso > perf.txt

then you would see that the 'period' (the number between the timestamp and the event name) would not (usually) be == 1.

If you use a 'perf record' cmd like below, you'll see a period of 1 in the 'perf script' output like:

Binder:695_5   695/2077  [000] 16231.700440:          1         sched:sched_switch: prev_comm=Binder:695_5 prev_pid=2077 prev_prio=120 prev_state=S ==> next_comm=kworker/u16:17 next_pid=7665 next_prio=120

A long winded explanation but basically: don't do that (where 'that' is '-F 999').

If you just do something like:

perf record -a -g -e sched:sched_switch -e sched:sched_blocked_reason -e sched:sched_stat_sleep -e sched:sched_stat_wait sleep 5

then the output would show every context switch with the call stack for each event. And you might need to do:

echo 1 > /proc/sys/kernel/sched_schedstats

to get the sched_stat events.

Linux Processes vs Threads – Understanding the Difference

Linux also provides the ability to create threads using the clone() system call. However, Linux does not distinguish between processes and threads. In fact, Linux uses the term task —rather than process or thread— when referring to a ﬂow of control within a program.

We need to distinguish between the actual implementation and the surface you see.

From user (system software developer) point of view there is a big difference: threads share a lot of common resources (e.g. memory mappings - apart from stack, of course - file descriptors).

Internally (warning: imprecise handwaving arguments) the Linux kernel¹⁾ is using what it has at hand, i.e. the same structure for processes and for threads, where for threads of a single process it doesn't duplicate some things rather it references a single instance thereof (memory map description).

Thus on the level of directly representing a thread or a process there is not much difference in the basic structure, the devil lies in how the information is handled.

You may as well be interested in reading Are threads implemented as processes on Linux?

¹⁾ Remember that "Linux" these days stands mostly for the whole OS, while in fact it only is the kernel itself.

Related Question