Subject: Re: UP N:1 vs. MP/UP 1:1 vs. MP/UP M:N and newlock2
To: Bucky Katz <bucky@picovex.com>
From: Matthew Mondor <mm_lists@pulsar-zone.net>
List: tech-kern
Date: 02/22/2007 12:49:43
On Wed, 21 Feb 2007 13:55:29 -0800
Bucky Katz <bucky@picovex.com> wrote:

> Actually, I'm asking for M:N where N ~= 2. But I'd settle for working
> N:1 as I can fake the rest.

If by N:1 you mean userspace only threads, you could try out libpth and
see how it behaves (although make sure to also enable its blocking
syscall wrapper support option at build time for the compatibility POSIX
threads layer).  GNU Pth is actually only a select(2) based system, so
it will not scale with SMP but should work rather well for I/O...

Note that Pth is not preemptive, so if a thread is blocked a while doing
number crunching it might need to explicitely yield, it's cooperative
multithreading.  Its syscall wrapper will however internally set the
non-blocking flag on sockets and will loop in its select based scheduler
automatically for other threads to be allowed cycles.

If the application is mostly I/O driven, I doubt that it would really
benefit from SMP also (unless it makes heavy usage of hashing,
encryption, compression or other number crunching activity).  In fact it
might have performed better if it was single threaded with blocking I/O
in a main kqueue event processing loop, but I understand that you
already have the application written and are probably not going to
overhaul it at that point.

If the main factor for wanting M:N is related to faster thread
creation/destruction, a pool of threads can be used which would be
assigned tasks via an efficient inter-threading messaging facility
(conditional variable and linked list based), with minimal changes to
the exiting code...  I have an example of such code at
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/tests/pthread_utils/
(mm_pthread_pool.[ch]).

--
Matt