Subject: Re: [linux-audio-dev] Next gen posix threading
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Jul 11 2001 - 17:25:04 EEST
>Has anyone looked at IBM's new linux threading stuff?
>http://oss.software.ibm.com/developerworks/projects/pthreads/
yes, i read it last week. i don't view it as particular
significant. here's the simple scoop.
there are kernel threads, which are execution contexts that the kernel
knows about, schedules, prioritizes, etc.
there are user-space threads, which the kernel knows nothing about,
but a user-space (i.e. in a library) scheduler multiplexes onto one or
more kernel threads.
the POSIX P.1003 spec doesn't say much about which of these models
are used, because it doesn't really care.
kernel threads are better when considering blocking behaviour: if a
thread carries out a blocking operation (e.g. a disk read), some other
thread (potentially from the same application) can use the
processor. with user-space threads, when the blocking operation
occurs, the underlying kernel thread blocks, and the user-space
scheduler cannot get another user-space thread to run because its
never executed (it would run in the same kernel thread as the one that
blocked).
user-space threads are better when considering speed: they typically
have to save only a subset of the register set and generally have less
other state that needs to be saved during a context switch.
the existing linuxthreads implementation that 99.5% of us are using as
part of glibc uses pure kernel threads. another way to describe this
is to say that linuxthreads is a 1:1 model, in which every user-space
thread corresponds to a kernel thread.
the IBM work is a POSIX P.1003 ("Pthreads") implementation that
supports other mappings (the so-called M:N model) so that, for
example, M user-space threads might be multiplexed on N kernel threads
(where M may be smaller, larger or equal to N).
the main benefit of such an implementation is that you can use the
same thread package for user-space threads as for kernel threads,
instead of using a dedicated user-space thread library and/or
linuxthreads.
however, it doesn't solve any of the really hard problems with
parallel programming, nor increase performance of the kinds of
parallelism that most audio program demonstrate, where temporal
interdependency is a key feature. in addition, it still doesn't solve
the problems with the user-space-OR-kernel scheduler model that are
solved by the scheduler activations model. but nobody has implemented
that for linux yet.
--p
This archive was generated by hypermail 2b28 : Wed Jul 11 2001 - 17:26:48 EEST