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

* anne_dolly00@yahoo.co.uk (Anne) schriebt:
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/lecture/process&threads/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".




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.



Huh.


Huh.



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... ;-)



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.



That depends on the threading library the user is using, and also on
the operating system.


That depends on the threading library the user is using, and also on
the operating system.



That depends on the operating system and on the scheduler.


Huh.



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.

Alf P. Steinbach wrote:

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).

Agree with the HUH! No way, no how, not over my dead body
as a kernel hacker.

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.)

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.

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.

--
Ñ
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

Alf P. Steinbach 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.

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.

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.

Right, no.

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.

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.

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.

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.

Anne wrote:
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? */

In article <c1k5n8$rga$1@Mercury.ev.co.yu>,
Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu> wrote:
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`