Does pthreads in Linux create user or kernel space threads?
Diwa
There seems to be many pthreads implementations.
How do I know which is the one installed on my linux box?
Thanks
Diwa
David Schwartz
> Does pthreads in Linux create user or kernel space threads?
As that term is normally understood, on typical modern UNIX systems,
pthreads are kernel threads. That may or may not mean what you think
it means.
> There seems to be many pthreads implementations.
> How do I know which is the one installed on my linux box?
You could read the documentation that came with it or ask your vendor.
On Linux, you may find getconf(_CS_GNU_LIBPTHREAD_VERSION) to be
useful inside a program. From a shell prompt, try "getconf
GNU_LIBPTHREAD_VERSION".
DS
Diwa
Thanks David.
On my 32 bit box, using getconf in shell gave me NPTL 0.60
On my 64 bit box, I got NPTL 2.4
Will trying googling to get more details about NTPL
Diwa
Got to know some more things.
If I set LD_ASSUME_KERNEL=2.4.10, then getconf returns
linuxthreads-0.10
Seems like linuxthreads was used in older kernels.
Dave Butenhof
Yes, that's correct. NPTL ("new pthreads library") was designed to take
advantage of substantial changes in the 2.6 kernel to provide an
application API that's compatible with the POSIX thread standard
behavior. (Note that this is a little more complicated, because Red Hat
initially ported many of those changes into an earlier kernel and used
NPTL.)
Before all that, Linuxthreads provided a rough semblance of POSIX
compatibility if you were careful, but with substantial overhead and
reliance on a manager thread. It was very clever; but it couldn't hope
to be fully compatible, and the "holes" could be a big issue for serious
portable code.
So when you have (or force the system to act as if it has) an earlier
kernel, you're forcing the system to fall back to the older Linuxthreads.
Diwa
nitpick - Isn't NPTL supposed to stand for Native POSIX Thread Library
and not "new pthreads library" ?
Btw, my original question arose while reading your book on Programming
with posix pthreads (the second time actually).
The book gave me the impression that all pthreads libs is in user
space.
Steve Watt
>Btw, my original question arose while reading your book on Programming
>with posix pthreads (the second time actually).
>The book gave me the impression that all pthreads libs is in user
>space.
Hence David Schwartz's comment about "what do you mean by user mode".
All POSIX APIs apply only to user mode; the current standards do
not apply to device drivers or anything else running inside the kernel.
The terms "user thread" and "kernel thread" are terribly confusing,
because many (most? all?) modern operating systems have threads that
run completely within the context of the kernel. The other likely
use of that pair of terms has to do with whether a thread is an entity
visible to the kernel scheduler.
POSIX, as a standard, makes no requirements one way or the other on the
implementation of threads. Indeed, when the standard was written,
few operating systems had separate kernel-schedulable threads within
a process. (See also KSE and LWP.)
David B.'s book talks about those implementations because they were
the reality of the time when it was written. Very few systems today
have pure user-level implementations of threads, because it's nearly
impossible to get correct without significant help from the kernel. If
you do all the work to get the user-mode threads working correctly,
you're very far down the path to get full kernel-schedulable threads
working.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
David Schwartz
> The book gave me the impression that all pthreads libs is in user
> space.
You're probably just using terms like "kernel threads" and "in user
space" in a confusing way. Many user-space libraries are wrappers that
manipulate kernel resources. The term "kernel threads" in a pthreads
context refers to the division of labor between the user-space and
kernel-space components and primarily with how the threads are
scheduled. Of course the threads are "user space" in the sense that
they normally execute in user space until a kernel all is made.
I would recommend simply avoiding the terminology. It's only very
rarely useful. (Fortunately, these days you only very rarely have to
deal with the particulars of any given pthreads implementation. And
when you do, it's for some very advanced and unusual reason.)
Note that this is not true for the old LinuxThreads library. It does
have a lot of odd quirks that require you to handle things specially
because it uses kernel threads with a kernel that wasn't really
designed to support pthreads. (They mostly involve PIDs, signal
handling, and credentials.)
DS
Dave Butenhof
>> Yes, that's correct. NPTL ("new pthreads library") was designed to take
>> advantage of substantial changes in the 2.6 kernel to provide an
>> application API that's compatible with the POSIX thread standard
>> behavior. (Note that this is a little more complicated, because Red Hat
>> initially ported many of those changes into an earlier kernel and used
>> NPTL.)
>
> nitpick - Isn't NPTL supposed to stand for Native POSIX Thread Library
> and not "new pthreads library" ?
Yeah, that was Ulrich's original phrase. I'll admit to redefining a
phrase that's really known to most people only by the abbreviation. I
find "native" to be a very misleading and unhelpful term in this
context, and while I appreciate the sentiment behind it, it was never
entirely accurate and I think has long since outlived its usefulness as
a "marketing catch phrase". Linuxthreads also used native Linux clone();
it just didn't have access to the kernel extensions and improvements to
provide POSIX compliance. NPTL is a newer thread API taking advantage of
the newer kernel capabilities. It's not so much "more native" as "newer
native". ;-)
> Btw, my original question arose while reading your book on Programming
> with posix pthreads (the second time actually).
> The book gave me the impression that all pthreads libs is in user
> space.
In one sense, yes. As already pointed out, POSIX doesn't say anything
about the operation of a POSIX system inside kernel space. Many systems
with full threading inside the kernel don't expose POSIX-like APIs or
models within the kernel; most of these systems existed long before
POSIX threads, and the POSIX APIs (and often even the UNIX APIs) are
mapped on top of something else. (E.g., Mach threads.) So while portable
user applications can use the portable and standard POSIX API, kernel
code can't. Very little kernel code can be all that portable anyway!
In another sense, when you call open() you're not directly calling a
kernel API; you're calling a user mode wrapper than generates a trap
into kernel mode, which is then decoded and dispatched to a kernel
routine that opens a file. With varying amounts of user-mode code
surrounding it, depending on the system you're using. The standards
define the behavior of the user-mode API; the division of labor and data
between kernel and user code is completely irrelevant to the
application. Pthread APIs are no different so, yeah; they're "user mode".
But I assume you're getting at a deeper issue regarding implementation
strategy, relating to how the "pthread" you create is scheduled onto a
compute resource.
The original pthread implementation (aka "DCE threads") was strictly
user mode (N to 1). However, it was also an implementation of an early
draft of the pthread spec that was marked clearly "do not specify or
implement". Sun wrote their own implementation of a later draft, much
closer to the final standard, that did 2-level scheduling (M to N); with
a user mode API that multiplexed multiple "posix thread" contexts on a
smaller set of kernel entities (LWPs). It had a lot of serious issues
that complicated true POSIX compliance, and was eventually abandoned in
favor of a new API that mapped each POSIX thread context directly into a
single dedicated LWP (1 to 1).
DCE threads was released on VMS, ULTRIX, early DEC OSF/1, Apollo
DomainUX, HP-UX, AIX, and a few others. I rototilled the implementation
to make a true POSIX threads core implementation, using 2-level
scheduling, for Tru64 UNIX and OpenVMS. They remain fully 2-level
scheduling, with a clean (though not perfect) model of coordination
between user and kernel schedulers (not quite the "holy grail" of
scheduler activations, and subject to some artifacts; but not bad). Of
course, both OSs with the migration through Compaq to HP have been
essentially relegated to the status of historical relics.
HP-UX still does 2-level scheduling. The genesis of NPTL is actually in
NGPT, a "next generation" Linux POSIX threads model developed
principally by IBM to support large-scale Java programming by
introducing a scalable 2-level conforming scheduling model to Linux.
Though it was roundly rejected by Linus, Ulrich stepped in to salvage
some of the kernel work and scale back to a clean POSIX conforming 1 to
1 thread model, NPTL.
Diwa
> Diwa wrote:
> > On Oct 14, 1:36 pm, Dave Butenhof <david.buten...@hp.com> wrote:
> >> Diwa wrote:
> > Btw, my original question arose while reading your book on Programming
> > with posix pthreads (the second time actually).
> > The book gave me the impression that all pthreads libs is in user
> > space.
> But I assume you're getting at a deeper issue regarding implementation
> strategy, relating to how the "pthread" you create is scheduled onto a
> compute resource.
Yes, I was trying to figure out whether mostly pthreads are 1:1 or N:1
or M:N .
(I should have used the terms user/kernel threads instead of user/
kernel space)
If pthreads are not 1:1 mapped, then it does not make sense to make a
program multithreaded (even on a multiprocessor) unless some of the
threads would do blocking I/O.
But with 1:1 mapping and multiprocessor, its makes sense (especially
for truly independent operation threads). This again, is the
impression I got from the Pthreads book.
Dave Butenhof
> On Oct 15, 8:05 am, Dave Butenhof <david.buten...@hp.com> wrote:
>> Diwa wrote:
>>> On Oct 14, 1:36 pm, Dave Butenhof <david.buten...@hp.com> wrote:
>>>> Diwa wrote:
>
>>> Btw, my original question arose while reading your book on Programming
>>> with posix pthreads (the second time actually).
>>> The book gave me the impression that all pthreads libs is in user
>>> space.
>
>> But I assume you're getting at a deeper issue regarding implementation
>> strategy, relating to how the "pthread" you create is scheduled onto a
>> compute resource.
>
> Yes, I was trying to figure out whether mostly pthreads are 1:1 or N:1
> or M:N .
> (I should have used the terms user/kernel threads instead of user/
> kernel space)
>
> If pthreads are not 1:1 mapped, then it does not make sense to make a
> program multithreaded (even on a multiprocessor) unless some of the
> threads would do blocking I/O.
No, that's not quite right. If threads are "N:1" mapped, you're getting
no benefit unless you can exploit blocking behavior to overlap
execution. There's no "compute benefit" from threading.
However, while the degree of "compute benefit" from 1:1 and N:M may vary
depending on the relative implementation efficiency; in either case
(presuming of course that you have multiple physical computational
resources) you CAN gain benefit for pure computational loads as well as
I/O overlap.
> But with 1:1 mapping and multiprocessor, its makes sense (especially
> for truly independent operation threads). This again, is the
> impression I got from the Pthreads book.
If all threads are compute-bound, an N:M scheduler behaves much like a
1:1 scheduler. Possibly with somewhat reduced efficiency; but the
difference is one of degree rather than kind. Since the threads
generally don't block, the mapping between user and kernel entities
generally won't be broken. Even if the N:M limits the kernel threads to
the number of physical compute resources, you haven't artificially
limited parallelism since no more can simultaneously execute anyway.
(Again, scheduling efficiency comes into play here in your final
performance results; but a "really good" N:M scheduler may even give
some advantages over a poor 1:1 scheduler in some cases.)