pthread_mutex_timedlock on sparc64

Kris Kennaway kris at obsecurity.org
Thu Apr 20 22:02:38 UTC 2006


On Thu, Apr 20, 2006 at 05:52:19PM -0400, Miles Nordin wrote:
> >>>>> "kk" == Kris Kennaway <kris at obsecurity.org> writes:
> 
>     kk> In practise libthr is the fastest thread package, although
>     kk> there must still be some reason we don't make it the default.
> 
> thanks for the answers.  makes sense, I think I've finally got it.
> 
> For those forced to read all my noise today that haven't already heard
> this 1:1 vs MxN thing debated to death, this is the last thing I read
> about it:
> 
>  http://www.sun.com/software/whitepapers/solaris9/multithread.pdf
> 
>  ``This is not to say that a good implementation of MxN model is
>    impossible, but simply that a good 1:1 implementation is probably
>    sufficient.  This paper does not attempt a discussion of the
>    relative merits of the MxN and 1:1 threading models.  The basic
>    thesis is that the quality of an implementation is often more
>    important.''
> 
> The context is, a bunch of papers were published since 1993 showing
> that MxN threads were the most performant, and FreeBSD kse, Solaris
> threads between 2.6 and 2.8, threads in OSF/1 (I think the kse guys
> cited some Digital paper?), and NetBSD Scheduler Activations are all
> based on the design in the original paper cited at the end of kse(2).
> 
> Sun scrapped scheduler activations in Solaris 2.9.  They had to write
> the above advertisement PDF to convince people who'd read all that
> research since '93 that the 1:1 threads really were performant, and
> that they didn't just wuss out after too many bugs and revert to a
> slow, obvious EnTee/Linux style thread subsystem.

As I said previously, the 1:1 implementation in FreeBSD is also
usually faster (often much faster) than M:N.  AFAIK, this is partly
due to the unavoidability (at least on architectures like x86) of
doing a syscall on thread context switch to save TLS state (this was
not addressed in the SA papers), which is what a scheduler
activations-like design was supposed to avoid.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20060420/ac08b2f7/attachment.pgp


More information about the freebsd-sparc64 mailing list