Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)

[Helge Hafting <helge.hafting@aitel.hist.no>]

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
> usleep(1).
>  
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/