Re: Spinlocks, yet again: analysis and proposed patches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlocks, yet again: analysis and proposed patches
Date
Msg-id 23028.1126622378@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlocks, yet again: analysis and proposed patches  (Greg Stark <gsstark@mit.edu>)
Responses Re: Spinlocks, yet again: analysis and proposed patches
Re: Spinlocks, yet again: analysis and proposed patches
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches
Next
From: Roman Neuhauser
Date:
Subject: bug #1702: nested composite types in plpgsql