Re: User/Kernel Level Threads

• Previous message: Bob Harris: "Re: No of files in a directory (performance)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 03 Mar 2004 17:30:38 GMT

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

• Previous message: Bob Harris: "Re: No of files in a directory (performance)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]