apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Ghent <da...@elemental.org>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Fri, 03 Aug 2001 13:35:02 GMT
On Fri, 3 Aug 2001, Aaron Bannert wrote:

| The usage of a thread-level yield is really orthogonal to the
| performance characteristics of the OS scheduler, even on two-level
| systems like Solaris. In all cases (one-level or two-level), thread
| libraries will at some point have to multiplex one kernel-level
| thread (aka LWP) across many user-space threads. If it happens to
| do this multiplexing on calls like blocking-IO, then that is ideal,
| but like the Netware guys pointed out, cpu-bound blocks that do
| not make any of the magic thread-multiplexing system calls will
| not yield the cpu to it's peer threads.

On Solaris 8, there's an alternate libthread libary that you can link
against, /usr/lib/lwp/libthread.so.1. This library is different from
/usr/lib/libthread.so.1 in that is provides a one-level threading
structure... where each user thread has it's own kernel LWP. The other
advantage it has is that it totally does away with the thread scheduler
that's in the current, normal libthread, and instead allows the kernel to
do the scheduling.

Sun has told me that this is the threading archetecture that they're
moving to for Solaris 9, as the two-level archetecture is showing alot of
locking and scheduling limitations.

So, I unscientifically tested this new library out. I put /usr/lib/lwp
ahead of /usr/lib in the $LD_LIBRARY_PATH and started mysqld. Running
'pldd' on the process confirmed that it was using the new library, and the
sql-bench I ran against it was about 40% faster than what I normally have
seen when using the standard libthread library.

Just my 0.02Pf.

/dale


Mime
View raw message