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
