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.

jam

----- Original Message -----
From: "Bill Sommerfeld" <sommerfeld@orchard.arlington.ma.us>
To: "John Maier" <jmaier@midamerica.net>; "John A. Maier"
<johnam@kemper.org>
Cc: "Jason R Thorpe" <thorpej@zembu.com>; <netbsd-users@netbsd.org>
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(),
read()]
> 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
won't
> > 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