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@mit.edu> writes:
> > Marko Kreen <marko@l-t.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073