From: Matthew Mondor Date: Sun, 4 Mar 2007 08:29:03 +0000 (+0000) Subject: *** empty log message *** X-Git-Tag: pgsql-branch-merge~5 X-Git-Url: http://git.pulsar-zone.net/?a=commitdiff_plain;h=7afd739e0f4fe1c92cfc752d024d1e7e1edf1a30;p=mmondor.git *** empty log message *** --- diff --git a/tests/pthread/README b/tests/pthread/README new file mode 100644 index 0000000..95be5d2 --- /dev/null +++ b/tests/pthread/README @@ -0,0 +1,112 @@ +$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.