DragonFly kernel List (threaded) for 2007-03
DragonFly BSD
DragonFly kernel List (threaded) for 2007-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/lib/libthread_xu/thread thr_create.c thr_exit.c thr_info.c thr_kern.c

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 14 Mar 2007 10:37:52 -0700 (PDT)

:100% great work Simon. Thanks!
:I've got a question or two for you and Matt about this new threading.
:1) How does this compare to NPTL (Native Posix Threading Library) in 
:Linux? I dont mean performance wise but in technology?

    Simon can probayl answer this one a lot better then me.  I am not
    familiar with NPTL at all.

:2) i've read through couple of historic threads in which you (matt) say 
:that ideally DragonFly should have M:NCPU threading and in another one 
:Simon says 1:1 is what we want to have. Is 1:1 just a step before or has 
:the M:N idea been abandoned. Not that it would suprise me as 
:Linux,Sun,FreeBSD either have already or are abandoning M;N for 1:1 for 
:performance and stability reasons.

    LWPs implement a 1:1 model, and I now strongly believe that a 1:1 model
    is the ONLY model that the kernel should try to implement natively.

    There is a very important distinction here.... I now think M:NCPU is
    very sustainable as a userland implementation, and almost completely
    unsustainable as a kernel implementation.

    LWP gives us a framework for a kernel 1:1 implementation and if we want
    to do M:NCPU (remember, libpthread is basically M:1 already, so we know
    M:NCPU can be done fairly easily in userland)... if we want to do M:NCPU
    we will do it on top of the kernel LWP framework and simply have one LWP
    per cpu instead of one LWP per thread.

    The really nice thing about this is that we can develop libpthread into
    M:NCPU and we can develop libthread_xu into 1:1, and then actually have
    the two available for performance testing and be able to choose which
    one is best to use for any given application.

    The focus is clearly going to be on libthread_xu. I have no intention
    of working on libpthread myself any time soon.  But I hope that someone
    will take up the M:NCPU mantle for libpthread once libthread_xu and
    the LWP implementation is fully operational.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]