On Mon, 15 Apr 2002 19:35:33 +0100
"Peter Stewart" <peter.stewart@sun.com> wrote:

> Hi,
> I am wondering whether NetBSD has a thread library which is similar to the
> Solaris thread model, eg user threads bound to LWPs. Is there a defacto
> standard thread library for NetBSD? I can see there are kernel threads, can
> these be scheduled over multiple processors (SMP)? Or does one just use a
> complete user-side thread library. I have a snapshot of the CURRENT
> workspace, the libpthread directory seems to be devoid of any .c files, have
> I missed something. Is there a pointer to recommended thread practices with
> NetBSD?

I also looked a bit into pthread support on NetBSD when I wanted to port some
of my software; I however was discouraged by the current state of both
mit-pthreads and unproven-pthreads at the time (two years ago).. there may
have been improvements, but at the time none of those had support for kernel
threads (I beleive that still today no syscall exports fork1() which would
be required to implement kernel support for threads (somewhat like clone()
on linux)). This means that they were all real user-space thread libraries
and that the illusion of concurrent async execution of threads have to be
maintained with a little effort (a thread must not cause the whole process
to sleep, and either yield() or use thread-safe function calls only).

I have found libpth to be a better implementation than mit or unproven threads
to use on netbsd, however it is released under the GPL license which may
or may not suit your particular projects. libpth also has support for message
queues among threads, and optionally provides mapping POSIX pthread_*() function
name mapping to internal native pth_*() functions. Of course this library has
no special support for multiprocess kernel thread support, but has to use
kernel-specific tricks to maintain stacks and context for each thread.

Without a thread library creating new processes for each thread, you usually
do not have a preemptive scheduler, and of course cannot benefit from
potential kernel SMP support.

For some projects the traditional SYS V IPC facilities may prove more useful,
where you actually can pre- fork() off a pool of processes and dispatch them
tasks, using queues, semaphores and shared memory... if the overhead of
calling fork() often is a problem.

Matt