|
Home > Archive > Unix True 64 > March 2004 > User/Kernel Level Threads
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
User/Kernel Level Threads
|
|
|
| Hello,
I am confused about User level Thread /Kernel Level Threads. Could you
please look at my following questions? Many thanks for your time
0- With Kernel Level thread, will the thread run on Kernel mode?
that's what i have read, thread (user) code so can run on the kernel
space, that's look very dangerous for me!
does thread kernel mode means really that the threads code is mapped
on the kernel space?
1- Java for instance provides a package to manage Threads at the user
level. If instead a user wants to implement threads at the kernel
level which package should he/she use when working on
1- Windows NT
2- Linux
2- If the user writes multithreaded code using user level library,
will these threads be automatically mapped (one to one or many to
many) to kernel level threads? Or it is up to the user to instruct
this, if yes how?
3- If kernel level threads are supported, will the operating
system schedule processes first and then threads or schedule directly
threads. If the latter case is assumed some processes may stave and
others substantially favoured!
4- When threads are created, each thread ll be associated with a
dedicated stack within the same process's address space. What
mechanism and policy is followed to protect each thread stack from the
other
Many thanks for your help
| |
| Alf P. Steinbach 2004-02-25, 5:34 pm |
| * anne_dolly00@yahoo.co.uk (Anne) schriebt:
>
> I am confused about User level Thread /Kernel Level Threads.
So was I when reading your question. But it's just a question of
terminology, so I plugged the term "kernel-level thread" into Guggle,
and out popped e.g.
<url:http://www-scf.usc.edu/~csci402/lec...eads/sld011.htm>
User-level threads:
* All thread management is done by the application.
* The kernel is not aware of the existence of threads.
* Thread switching does not require kernel mode privileges.
* Scheduling is application specific.
Kernel-level threads:
* Windows/NT and OS/2 are examples of this approach.
* Kernel maintains context information for the process and the threads.
* Switching between threads requires the kernel.
Now these definitions should of course not be read too literally. E.g.
one can easily imagine a situation where not all thread management is done
by the application (so not user-level thread according to above), but where
switching between threads does not always require the kernel (so not kernel-
level thread). Instead, I think the points are meant as "typical features".
> Could you
> please look at my following questions? Many thanks for your time
>
> 0- With Kernel Level thread, will the thread run on Kernel mode?
No, not necessarily and not even usually, and it's not even necessarily
meaningful to say that a "thread runs in kernel (protected) mode"; it will
switch back and forth between privilege levels as it calls and returns from
operating system API functions.
> that's what i have read, thread (user) code so can run on the kernel
> space, that's look very dangerous for me!
Huh.
> does thread kernel mode means really that the threads code is mapped
> on the kernel space?
Huh.
> 1- Java for instance provides a package to manage Threads at the user
> level.
The threading support in Java can be user-level threads or kernel-level
threads depending on the system the Java application is executed on. You
don't really need to know. Unless you're into real-time systems programming,
in which case you'll probably not be using Java anyway... ;-)
> If instead a user wants to implement threads at the kernel
> level which package should he/she use when working on
>
> 1- Windows NT
>
> 2- Linux
That depends mainly on the language, and less on the operating system.
For example, in C++ one might use Boost.Threads, in C one might use
PThreads, in Java the built-in Java threads.
> 2- If the user writes multithreaded code using user level library,
> will these threads be automatically mapped (one to one or many to
> many) to kernel level threads?
That depends on the threading library the user is using, and also on
the operating system.
> Or it is up to the user to instruct this, if yes how?
That depends on the threading library the user is using, and also on
the operating system.
> 3- If kernel level threads are supported, will the operating
> system schedule processes first and then threads or schedule directly
> threads.
That depends on the operating system and on the scheduler.
> If the latter case is assumed some processes may stave and
> others substantially favoured!
Huh.
> 4- When threads are created, each thread ll be associated with a
> dedicated stack within the same process's address space. What
> mechanism and policy is followed to protect each thread stack from the
> other
Essentially there is very little protection between threads in the same
process no matter what threading library or OS you're using, because the
main point of threads is to have very little overhead in context switches.
One alternative might be to use Light-Weight Processes (LWPs) in *nix,
but I don't know more about that than that some people have recommended it.
Since you have cross-posted to a lot of *nix groups I expect you'll get
a lot more information about that, or possibly that someone has fed me
some disinformation.
> Many thanks for your help
| |
| Nick Landsberg 2004-02-25, 5:34 pm |
|
Alf P. Steinbach wrote:
> * anne_dolly00@yahoo.co.uk (Anne) schriebt:
>=20
>=20
>=20
> So was I when reading your question. But it's just a question of
> terminology, so I plugged the term "kernel-level thread" into Guggle,
> and out popped e.g.
> <url:http://www-scf.usc.edu/~csci402/lec...ads/sld011.htm=
>
>=20
>=20
> User-level threads:
> * All thread management is done by the application.
> * The kernel is not aware of the existence of threads.
> * Thread switching does not require kernel mode privileges.
> * Scheduling is application specific.
>=20
> Kernel-level threads:
> * Windows/NT and OS/2 are examples of this approach.
> * Kernel maintains context information for the process and the thread=
s.
> * Switching between threads requires the kernel.
>=20
>=20
> Now these definitions should of course not be read too literally. E.g.=
> one can easily imagine a situation where not all thread management is d=
one
> by the application (so not user-level thread according to above), but w=
here
> switching between threads does not always require the kernel (so not ke=
rnel-
> level thread). Instead, I think the points are meant as "typical featu=
res".
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> No, not necessarily and not even usually, and it's not even necessarily=
> meaningful to say that a "thread runs in kernel (protected) mode"; it w=
ill
> switch back and forth between privilege levels as it calls and returns =
from
> operating system API functions.
>=20
>=20
It would probably be meaningful to say that certain kernels
support thread scheduling on behalf of a process within the kernel
scheduler. This implies that different threads may run on different
CPU's if it is more than a single-CPU box. On those platforms
which do not provide kernel support of thread scheduling, all
threads run on the same CPU as the process (and if you're CPU bound,
rather than I/O bound, threading buys you nothing).
>=20
>=20
>=20
>=20
> Huh.
Agree with the HUH! No way, no how, not over my dead body
as a kernel hacker.
>=20
>=20
>=20
>=20
>=20
> Huh.
See above. Thread scheduling is supported by some kernels. I know of
know implementation which maps user code into kernel space.
(Doesn't mean there aren't any, just that I don't know of one.)
>=20
> =20
> =20
>=20
>=20
>=20
> The threading support in Java can be user-level threads or kernel-level=
> threads depending on the system the Java application is executed on. Y=
ou
> don't really need to know. Unless you're into real-time systems progra=
mming,
> in which case you'll probably not be using Java anyway... ;-)
>=20
>=20
Depends on what you mean by "real time." 
I was once involved in a project review which was
talking about "real time billing." It took me
quite a while to digest that to them "real time"
was "under 5 minutes" while all that time I was
thinking in sub-milliseconds as the benchmark.
>=20
>=20
>=20
>=20
> That depends mainly on the language, and less on the operating system.
>=20
> For example, in C++ one might use Boost.Threads, in C one might use
> PThreads, in Java the built-in Java threads.
>=20
> =20
> =20
>=20
>=20
>=20
> That depends on the threading library the user is using, and also on
> the operating system.
>=20
>=20
>=20
>=20
>=20
> That depends on the threading library the user is using, and also on
> the operating system.
>=20
>=20
>=20
>=20
>=20
>=20
> That depends on the operating system and on the scheduler.
>=20
>=20
>=20
>=20
>=20
> Huh.
>=20
>=20
Now we are getting into something akin to "real-time". I presume the
typo above meant "starve." As far as I am concerned, the usual kernel
scheduling algorithms are not for mere mortals to understand. They
are geared to a time-sharing environment where you are penalized (but
not too much) for excessive CPU usage. It depends on the
implementation, but as I remember (possibly incorrectly),
once a process has been context switched out, it goes on a
run-queue and this is maintained in FIFO order. (If the
process or thread is blocked by a blocking system call, it
does not go on the run queue until the blocking system call
is satisfied). The FIFO ordering is a half-hearted way to
avoid starvation.
> =20
>=20
>=20
>=20
> Essentially there is very little protection between threads in the same=
> process no matter what threading library or OS you're using, because th=
e
> main point of threads is to have very little overhead in context switch=
es.
>=20
> One alternative might be to use Light-Weight Processes (LWPs) in *nix,
> but I don't know more about that than that some people have recommended=
it.
>=20
> Since you have cross-posted to a lot of *nix groups I expect you'll get=
> a lot more information about that, or possibly that someone has fed me
> some disinformation.
>=20
>=20
>=20
>=20
>=20
--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch
| |
| Nikola Milutinovic 2004-02-26, 2:34 am |
| Alf P. Steinbach wrote:
> * anne_dolly00@yahoo.co.uk (Anne) schriebt:
>
> User-level threads:
> * All thread management is done by the application.
> * The kernel is not aware of the existence of threads.
> * Thread switching does not require kernel mode privileges.
> * Scheduling is application specific.
>
> Kernel-level threads:
> * Windows/NT and OS/2 are examples of this approach.
> * Kernel maintains context information for the process and the threads.
> * Switching between threads requires the kernel.
>
>
> Now these definitions should of course not be read too literally. E.g.
> one can easily imagine a situation where not all thread management is done
> by the application (so not user-level thread according to above), but where
> switching between threads does not always require the kernel (so not kernel-
> level thread). Instead, I think the points are meant as "typical features".
One other difference: thread switching. It is mentioned up there, but let me
underline it. In User-level threads, if a thread goes into a dead loop, the
entire "UL thread system" of that process will be locked, since there is nothing
available to perform the switch to another thread. The switch is volountary.
With Kernel-level threads, the kernel switches threads. If one of them goes into
a dead loop, it will be switched by the kernel pre-emtion routine and possibly
scheduled to lower priority, due to it's high CPU usage. Other threads in the
same process will be given their share of CPU.
[color=darkred]
>
> Huh.
Yup! Only when a process calls a system API, the process (or a thread, in this
case) will be switched to a kernel mode and will jump to a fixed procedure
entrance point in the kernel code. There is no room for hacking here, it is done
by the CPU.
>
> Huh.
Right, no.
>
> That depends mainly on the language, and less on the operating system.
>
> For example, in C++ one might use Boost.Threads, in C one might use
> PThreads, in Java the built-in Java threads.
Three commercially available OSes that have MACH architecture (or close to it)
are Windows NT, Tru64 UNIX (a.k.a. Digital UNIX (a.k.a. DEC OSF/1)) and MacOS X.
These have native kernel level threads, preemtive kernel, SMP support,... Linux
is closing in, with kernel 2.6.
>
> That depends on the operating system and on the scheduler.
Yes, but most commonly, kernel schedules threads, which are assigned to
scheduling classes, with respect to priority. Scheduling algorithms can get
pretty complex, factoring in priority class, time already given to the thread, etc.
[color=darkred]
It is the job of a thread scheduler to see that *that* doesn't happen. Usually,
a thread that has been given a CPU, will be assigned some "weight" points, which
will be subtracted from the calculated priority level.
[color=darkred]
One of the main goals of multi-threading is to have threads which can cooperate
on the same memory region, without the cumbersome protection mechanisms.
Therefore, there is no protection between threads *of the same process*. If you
shoot yourself in the foot - it's your foot.
Nix.
| |
| Kasper Dupont 2004-02-26, 8:34 am |
| Anne wrote:
>
> Hello,
>
> I am confused about User level Thread /Kernel Level Threads. Could you
> please look at my following questions? Many thanks for your time
>
> 0- With Kernel Level thread, will the thread run on Kernel mode?
> that's what i have read, thread (user) code so can run on the kernel
> space, that's look very dangerous for me!
I think part of the confusion comes from the fact,
that the term "kernel threads" have been used about
two different things.
If a user mode program needs to use threads, they
can either be implemented in user mode or be a
feature offered by the kernel. The later have been
called kernel threads.
In Linux a handfull of the threads on the system
will be a part of the kernel handling various
kernel tasks, they are also called kernel threads,
but are something completely different from the
other kernel threads.
When a user mode program needs threads, the two
possibilities each have advantages and disadvantages.
Threads implemented in user mode have the advantage,
that they can be used even if the kernel doesn't
offer any threading. And thread switching can be
very fast. Except from those two points, threads
implemented in user mode have only disadvantages.
Threads implemented in user mode will not allow
more than one thread to run at any time even if
there are multiple CPUs. And even worse, if a thread
is blocked in a system call, that thread will still
occupy the process, so no other thread can execute
because the process is sleeping.
I have heard of hybrid user/kernel mode thread
implementations. But they have got to be very
complicated, and I doubt they have any major
advantages over an implementation 100% in kernel
mode.
The only real advantage of user mode threads when
kernel support for threads exists is the overhead
for switching between two threads. And that is only
significant if your program requires a lot of
switches between threads.
In Linux a lot of work have been done to keep the
overhead for switching between threads low. From
the kernel's point of view, the only thing special
about threaded programs compared to non-threaded
programs, is the fact that multiple user tasks
with same virtual memory space exists. And it will
use this knowledge to do
1) Lazy switching, which means only switch memory
map when it is strictly necesarry.
2) Give tasks with same virtual memory space as the
last used slightly higher priority when picking
the next task to be scheduled.
I have not heard about other systems that have made
the same effort to improve threading performance.
I haven't seen any comparisions between threads
using the Linux kernel, and threads implemented in
user space, so I don't know if there is any
significant difference in switching overhead.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */
| |
| Peter da Silva 2004-02-27, 12:34 pm |
| In article <c1k5n8$rga$1@Mercury.ev.co.yu>,
Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu> wrote:
> One other difference: thread switching. It is mentioned up there, but let me
> underline it. In User-level threads, if a thread goes into a dead loop, the
> entire "UL thread system" of that process will be locked, since there is
> nothing
> available to perform the switch to another thread. The switch is volountary.
That's an implementation detail. You can have user-level threads that are
switched on a software interrupt. I don't know if there are any user-level
threads packages for end-user operating systems that switch on signals,
but it's not unheard of for real-time systems.
--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`
| |
| John R 2004-03-03, 12:35 pm |
| I think we need to define a few things:
Since we are in the TRU64 newsgroup, lets deal with Tru64
specifically.
Tru64 kernel is based on the Mach model
User threads have 2 possibilities:
PCS threads (many to one model)
SCS threads (one to one model)
PCS threads is the default configuration
On 25 Feb 2004 13:11:47 -0800, anne_dolly00@yahoo.co.uk (Anne) wrote:
>Hello,
>
>I am confused about User level Thread /Kernel Level Threads. Could you
>please look at my following questions? Many thanks for your time
>
>0- With Kernel Level thread, will the thread run on Kernel mode?
>that's what i have read, thread (user) code so can run on the kernel
>space, that's look very dangerous for me!
>does thread kernel mode means really that the threads code is mapped
>on the kernel space?
No, the user level threads will run in user space, independent of the
threads model used.
>
>
>1- Java for instance provides a package to manage Threads at the user
>level. If instead a user wants to implement threads at the kernel
>level which package should he/she use when working on
>
>1- Windows NT
>
>2- Linux
>
>
>
>2- If the user writes multithreaded code using user level library,
>will these threads be automatically mapped (one to one or many to
>many) to kernel level threads? Or it is up to the user to instruct
>this, if yes how?
It is up to the user to implement the threads as they want. We do
not stop the user from shooting himself in the foot. As already
mentioned, PCS (many to one) is the default configuration on Tru64
Unix. See pthread_attr_setscope()
>
>3- If kernel level threads are supported, will the operating
>system schedule processes first and then threads or schedule directly
>threads. If the latter case is assumed some processes may stave and
>others substantially favoured!
Using PCS threads, scheduling is done in the threads library
Using SCS threads, scheduling is done by the kernel
There is always a chance of starvation, independent of the scheduling
policy. We strongly recommend that the user not attempt to use
policies and priorites to define application behavior.
>
>4- When threads are created, each thread ll be associated with a
>dedicated stack within the same process's address space. What
>mechanism and policy is followed to protect each thread stack from the
>other
There is a guard page (with a yellow zone) around each stack.
I will restate that we do nothing to stop you from shooting yourself
in the foot. You could set the deafullt stack size such that you
will have stack overflow. Determining optimum stack size can take
some tweaking and adjusting.
Starting in Version 5.0, for threads that accept the default stack
address attribute, the Threads Library allocates a thread's writable
stack area from uncommitted virtual memory, then commits predefined
increments of the writable stack area to the thread only as it is
needed. The stack's corresponding backing store is also reserved
incrementally as the stack is committed. In this way, no more backing
store is reserved than the stack actually requires.
Because Tru64 UNIX 5.0 does not commit backing store (or physical
pages) for stacks until the pages are used by the program, the default
stack size has been increased. The previous default of about 24Kb (3
pages) has been increased to 5Mb.
John Reguera
|
|
|
|
|