Re: Spinlocks, yet again: analysis and proposed patches

I have removed this TODO item:

* Research use of sched_yield() for spinlock acquisition failure

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073