Subject: Re: native pthread support in 1.5
To: John Maier <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 08/29/2000 12:03:29
> So an app written with threading will show up as one process?
> 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?
> 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.