Re: User/Kernel Level Threads
From: Nikola Milutinovic (Nikola.Milutinovic_at_ev.co.yu)
Date: 02/26/04
- Next message: Fredrik: "Re: How to see memory configuration?"
- Previous message: Tim: "Re: PWS600au CPU Serial number"
- In reply to: Alf P. Steinbach: "Re: User/Kernel Level Threads"
- Next in thread: Peter da Silva: "Re: User/Kernel Level Threads"
- Reply: Peter da Silva: "Re: User/Kernel Level Threads"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 26 Feb 2004 08:03:20 +0100
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.
>>Could you
>>please look at my following questions? Many thanks for your time
>>that's what i have read, thread (user) code so can run on the kernel
>>space, that's look very dangerous for me!
>
> 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.
>>does thread kernel mode means really that the threads code is mapped
>>on the kernel space?
>
> Huh.
Right, no.
>>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.
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.
>>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.
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.
>>If the latter case is assumed some processes may stave and
>>others substantially favoured!
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.
>>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
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.
- Next message: Fredrik: "Re: How to see memory configuration?"
- Previous message: Tim: "Re: PWS600au CPU Serial number"
- In reply to: Alf P. Steinbach: "Re: User/Kernel Level Threads"
- Next in thread: Peter da Silva: "Re: User/Kernel Level Threads"
- Reply: Peter da Silva: "Re: User/Kernel Level Threads"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
