Re: Spinlocks, yet again: analysis and proposed patches

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Marko Kreen <marko(at)l-t(dot)ee> writes:
> (I speculate that it's set up to only yield the processor to other
> processes already affiliated to that processor. In any case, it
> is definitely capable of getting through 10000 yields without
> running the guy who's holding the spinlock.)

> Maybe it should try sched_yield once and then use select after that?

I tried that, actually, but it didn't seem to offer any particular
benefit. (Maybe it would have helped more on older Linux kernels before
they changed sched_yield?)

I'm feeling even more disenchanted with sched_yield now that Marko
pointed out that the behavior was changed recently. Here we have a
construct that is not portable cross-platform, does not act as
documented in its man page, and the kernel guys feel free to whack its
behavior around in major ways without documenting that either. It seems
to be a crap-shoot whether it will be useful on any particular machine
or not. At least with the select() code we can be reasonably confident
we know what will happen.

regards, tom lane