--- /dev/null
+$Id: README,v 1.1 2007/03/04 08:29:03 mmondor Exp $
+
+Copyright (c) 2007, Matthew Mondor
+ALL RIGHTS RESERVED.
+
+
+The status of POSIX threads on the NetBSD operating system
+==========================================================
+
+For a long while (until 2.0 release) NetBSD had no native POSIX
+threading interface. It had support for kernel threads and
+processes only, and required external user 1:N thread library
+packages to support the pthread interface (using sigaltstack(2) or
+equivalent and a polling scheduler around select(2) or equivalent,
+nor providing pre-emptive threads). This means that special care
+had to be taken by the programmer not to starve other threads
+performing number crunching without yielding explicitely, or block
+the whole process by using unwrapped blocking syscalls.
+Unproven-threads, and GNU Pth could be used, which would provide
+non-blocking wrappers around the blocking I/O syscalls.
+
+Starting from 2.0, NetBSD shipped with a native M:N POSIX threads
+implementation using Scheduler Activations. This implementation,
+still used in a more mature form in NetBSD 4.x, works with an
+impressive performance on uniprocessor systems. It also conforms
+very well to the standard on various tricky aspects on which
+LinuxThreads failed to comply (one of the reasons LPTL replaced
+them on Linux). However, the multiprocessor support or adjustable
+PTHREAD_CONCURRENCY still has stability issues on v4.
+
+That M:N model relied on a userland library making use of
+Scheduler Activations in order to only spawn as many Light Weight
+Processes (actual real kernel supported threads in the same
+process) as required, such that non-blocking I/O operations and
+such done by many threads may be done more efficiently with fewer
+CPU/kernel context switches.
+
+On NetBSD -current (4.99.x), it was considered that the Scheduler
+Activations system on which the previous M:N model was implemented
+had scalibility issues as well as major problems to adapt to
+multi-processor systems. Since the SA author and other developers
+did not put efforts into re-writing or major rehauling SA, the
+threading model was changed to a 1:1 model.
+
+This occurred as major work was being done on better locking (in
+an effort to eliminate the big lock). To prevent M:N from hindering
+SMP enhancements a migration was made from M:N to a 1:1 model,
+that-is, one LWP per thread such as is the case for Linux, Solaris
+(which used to support an M:N model but dropped it at some point,
+apparently because of complexity issues), and other BSDs.
+
+
+M:N could scale in all situations
+=================================
+
+Although the current 1:1 model is all good for SMP, the performance
+on uniprocessors was still unprecendented by the M:N model.
+Moreover, if SA was re-written, or that another M:N threading model
+was developped, it could still benefit both uniprocessor and
+multiprocessor ones while scaling potentially even better than 1:1
+with SMP.
+
+Therefore while thinking about the problem here and then and
+through various tests, notes will be taken here on various ideas
+through which a new M:N model could be developped. If I am
+eventually able to dedicate enough time and resources, an
+alternative pthread library might be written here as well, which
+could potentially be submitted for testing and review to NetBSD
+developers for eventual inclusion in v5 or v6 release.
+
+
+Various challenges and ideas
+============================
+
+- A kqueue userland thread scheduler could be written, although it
+ would probably need some support similar to AIO for disk I/O
+ operations which could be blocking.
+
+- A function can be called by libc prior to main() call to setup
+ the threading library. However, a non-threading process is
+ considered to be a process with one single thread but which must
+ behave like traditionally.
+ Perhaps that the thread scheduler could be launched when the
+ first pthread_init() call is made. The main LWP could become
+ the thread scheduler LWP.
+
+- Special minimal kernel support might be necessary for the
+ scheduler to detect efficiently when to spawn a new LWP in its
+ queue.
+
+- The scheduler should be able to automatically permanently bind
+ to a LWP a number-crunching thread which requires pre-emptive
+ yielding.
+ It is possible that we simply need to delegate to another LWP
+ any pre-empted operation done in the first LWP (which is also
+ the userland scheduler).
+
+- Actually, as long as pthread_create() was at least called once,
+ as soon as a all LWPs are preempted or blocked, a new LWP must
+ become available...
+
+- If the main LWP scheduler could perform all operations in a
+ non-blocking manner, only threads requireing pre-emption would
+ need to be mapped to a new LWP especially created for them...
+ However there may also be non-I/O blocking system and libc
+ calls.
+
+- The current LWP system doesn't have provision for asynchroneous
+ _lwp_wait() which would be needed for M:N pthread_join()
+ implementation.
+
+- It would also be nice to have configurable per-LWP CPU afinity.
Repositories / mmondor.git / commitdiff