Messages in this thread |  | | | Date | Mon, 30 Jan 2006 16:15:56 +0100 | | From | Helge Hafting <> | | Subject | Re: 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 >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/
|  |