[lkml]   [2006]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    linux-os (Dick Johnson) wrote:

    >On Mon, 30 Jan 2006, Helge Hafting wrote:
    >>linux-os (Dick Johnson) wrote:
    >>>To fix the current problem, you can substitute usleep(0); It will
    >>>give the CPU to somebody if it's computable, then give it back to
    >>>you. It seems to work in every case that sched_yield() has
    >>>mucked up (perhaps 20 to 30 here).
    >>Isn't that dangerous? Someday, someone working on linux (or some
    >>other unixish os) might come up with an usleep implementation where
    >>usleep(0) just returns and becomes a no-op. Which probably is ok
    >>with the usleep spec - it did sleep for zero time . . .
    >Dangerous?? You have a product that needs to ship. You can make
    >it work by adding a hack. You add a hack. I don't see danger at
    >all. I see getting the management off the back of the software
    >engineers so that they can fix the code. Further, you __test__ the
    >stuff before you ship. If usleep(0) just spins, then you use
    The dangerous part was that usleep(0) works as a "yield"
    today, as your testing will confirm before you ship the product.
    But it may break next year if someone changes this part of
    the kernel. Then your customer suddenly have a broken product.

    Helge Hafting
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-30 16:13    [W:0.103 / U:64.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site