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

Groups > comp.programming.threads > #648

Re: User threads

Show all headers | View raw

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.

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web