Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #647 > unrolled thread

User threads

Back to article view | Back to comp.programming.threads

Contents

  User threads divcurl <divcurl@europe.com> - 2011-10-19 18:06 -0700
    Re: User threads Robert Wessel <robertwessel2@yahoo.com> - 2011-10-19 23:16 -0500
      Re: User threads Alexander Terekhov <terekhov@web.de> - 2011-10-20 14:32 +0200

#647 — User threads

I've been reading an operating systems book by silberschatz(sp?) and
it talks about kernel threads and user threads.  However, it doesn't
make clear the fundamental distinction between the two.  In other
words, are user threads just part of a threaded library that
ultimately
uses appropriate system calls and ends up being mapped(in some
fashion)
to kernel thread(s)?  Apparently, it is possible to implement user
threads, or threads in user space, without any kind of mapping
to kernel threads.  This seems to be achieved via some kind of
timer mechanism and managing tables that contain information
related to each thread.  So in effect we give the appearance of
a multi-threaded environment through the use of timers.  However,
is this a common way of implementing user threads or is it often
the case that user threads end up being mapped to kernel threads?
Or does the definition of user threads restrict the threads to
userspace
only?

Clarification welcomed.

[toc] | [next] | [standalone]

#648

On Wed, 19 Oct 2011 18:06:11 -0700 (PDT), divcurl <divcurl@europe.com>
wrote:

>I've been reading an operating systems book by silberschatz(sp?) and
>it talks about kernel threads and user threads.  However, it doesn't
>make clear the fundamental distinction between the two.  In other
>words, are user threads just part of a threaded library that
>ultimately
>uses appropriate system calls and ends up being mapped(in some
>fashion)
>to kernel thread(s)?  Apparently, it is possible to implement user
>threads, or threads in user space, without any kind of mapping
>to kernel threads.  This seems to be achieved via some kind of
>timer mechanism and managing tables that contain information
>related to each thread.  So in effect we give the appearance of
>a multi-threaded environment through the use of timers.  However,
>is this a common way of implementing user threads or is it often
>the case that user threads end up being mapped to kernel threads?
>Or does the definition of user threads restrict the threads to
>userspace
>only?


User level threads have been implemented on many systems.  Before most
Unix systems had kernel threads, that was the most common
implementation on Unix.

The exact mechanisms you need are very environment dependent, but most
user level thread packages work by managing their own context
switching (which is not hard), and wrapping all (potentially) blocking
system calls so that they can be executed in non-blocking form while
other threads are allowed to continue to run.  You really only "need"
timers if you want preemptive tasking.  Note that some implementations
use timers to get control back (via a signal) during a long system
call, and use that signal to dispatch another thread.

A major limitation of user level threading is lack of support for
multiple processors.  An issue is that you have to wrap a great number
of system calls, which obviously presents a maintenance issue.  Also
properly wrapping the system calls usually requires some nasty poking
into things to replace those entry points, or modification of the
executables to use the wrappers instead.

The other extreme is pure kernel level threading, which is the most
common approach today.  Usually the overhead of kernel threads is a
fair bit higher than user level threads.

Hybrid schemes have been implemented where N user level threads are
mapped onto M kernel threads, the goal being the combination of low
overhead of user level threads and the multiple processor support of
kernel threads.  This is actually quite attractive, since the vast
majority of threads exist more for control-flow reasons, rather than
making use of multiple processors.  But the difficulty of
implementation has mostly eliminated that as an approach.

[toc] | [prev] | [next] | [standalone]

#649

Robert Wessel wrote:
[...]
> Hybrid schemes have been implemented where N user level threads are
> mapped onto M kernel threads, the goal being the combination of low
> overhead of user level threads and the multiple processor support of
> kernel threads.  This is actually quite attractive, since the vast
> majority of threads exist more for control-flow reasons, rather than
> making use of multiple processors.  But the difficulty of
> implementation has mostly eliminated that as an approach.

From 

http://publib.boulder.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.prftungd/doc/prftungd/prftungd_pdf.pdf

"Thread tuning

User threads provide independent flow of control within a process.

If the user threads need to access kernel services (such as system
calls), the user threads will be serviced by associated kernel threads.
User threads are provided in various software packages with the most
notable being the pthreads shared library (libpthreads.a). With the
libpthreads implementation, user threads sit on top of virtual
processors (VP) which are themselves on top of kernel threads. A
multithreaded user process can use one of two models, as follows:

1:1 Thread Model

The 1:1 model indicates that each user thread will have exactly one
kernel thread mapped to it. This is the default model on AIX 4.1, AIX
4.2, AIX 4.3, and AIX 6.1. In this model, each user thread is bound to a
VP and linked to exactly one kernel thread. The VP is not necessarily
bound to a real CPU (unless binding to a processor was done). A thread
which is bound to a VP is said to have system scope because it is
directly scheduled with all the other user threads by the kernel
scheduler.

M:N Thread Model

The M:N model was implemented in AIX 4.3.1 and is also now the default
model. In this model, several user threads can share the same virtual
processor or the same pool of VPs. Each VP can be thought of as a
virtual CPU available for executing user code and system calls. A thread
which is not bound to a VP is said to be a local or process scope
because it is not directly scheduled with all the other threads by the
kernel scheduler. The pthreads library will handle the scheduling of
user threads to the VP and then the kernel will schedule the associated
kernel thread. As of AIX 4.3.2, the default is to have one kernel thread
mapped to eight user threads. This is tunable from within the
application or through an environment variable.

Depending on the type of application, the administrator can choose to
use a different thread model. Tests on AIX 4.3.2 have shown that certain
applications can perform much better with the 1:1 model. The default
thread model was changed back to 1:1 from M:N in AIX 6.1, but for AIX
4.3.1 to AIX 6.1, by simply setting the environment variable
AIXTHREAD_SCOPE=S for that process, we can set the thread model to 1:1
and then compare the performance to its previous performance when the
thread model was M:N.

If you see an application creating and deleting threads, it could be the
kernel threads are being harvested because of the 8:1 default ratio of
user threads to kernel threads. This harvesting along with the overhead
of the library scheduling can affect the performance. On the other hand,
when thousands of user threads exist, there may be less overhead to
schedule them in user space in the library rather than manage thousands
of kernel threads. You should always try changing the scope if you
encounter a performance problem when using pthreads; in many cases, the
system scope can provide better performance."

regards,
alexander.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web