Subject: Re: native pthread support in 1.5
To: Bill Sommerfeld <>
From: John Maier <>
List: netbsd-users
Date: 08/29/2000 14:29:13
I see what is going on!

I was unclear as to where the threads were occurring.

There are just so many ways to accomplish threading, I assumed that the LWP
meant that all the threading was occurring in userland libs.

Never mind I understand now.  It all makes sense now.


----- Original Message -----
From: "Bill Sommerfeld" <>
To: "John Maier" <>; "John A. Maier"
Cc: "Jason R Thorpe" <>; <>
Sent: Tuesday, August 29, 2000 11:03 AM
Subject: Re: native pthread support in 1.5

> > So an app written with threading will show up as one process?
> Yes.
> > If I am understanding you correctly, The NetBSD implementation will be a
> LWP > with kernel tie ins to keep calls that block [i.e. connect(),
> from > hanging the other threads?
> Yes.
> > If this is true, then how might this be moved to a multiprocessor
> > architecture model?  I realize that LWP threading has typically superior
> > performance to HWP, where number crunching is *not* involved, but it
> > take advantage of a multiprocessor system.
> there's a terminology mismatch going on here.
> LWP is sometimes used to refer to userland-only threading.  this is
> not what netbsd is doing.  We're using the solaris-like terminology
> here; a process has multiple kernel-visible lwp's within it.
> The userland scheduler will be responsible for assigning user-level
> pthreads to the kernel lwp's.
> Preempted user-level threads, as well as threads which are waiting for
> user-level events (blocked waiting for a pthread_mutex_lock or
> pthread_cond_wait) will not tie up a kernel lwp.
> > I assume that floating point will be an in kernel solution to maintain
> > performance where number crunching is required.
> huh?  floating point will run on the native FP hardware unless
> emulation is needed.
> - Bill