On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> Since it better be legal to manipulate a atomic variable while holding a
> spinlock we cannot simply use an arbitrary spinlock as backing for
> atomics. That'd possibly cause us to wait on ourselves or cause
> deadlocks.
I think that's going to fall afoul of Tom's previously-articulated "no
loops inside spinlocks" rule. Most atomics, by nature, are
loop-until-it-works.
>> How much would we lose if we supported compiler intrinsics on
>> versions of GCC and MSVC that have it and left everything else to
>> future patches?
>
> The discussion so far seemed pretty clear that we can't regress somewhat
> frequently used platforms. And dropping support for all but msvc and gcc
> would end up doing that. We're going to have to do the legword for the
> most common platforms... Note that I didn't use assembler for those, but
> relied on intrinsics...
We can't *regress* somewhat-frequently used platforms, but that's
different from saying we've got to support *new* facilities on those
platforms. Essentially the entire buildfarm is running either gcc,
some Microsoft compiler, or a compiler that's supports the same
atomics intrinsics as gcc i.e. icc or clang. Some of those compilers
may be too old to support the atomics intrinsics, and there's one Sun
Studio animal, but I don't know that we need to care about those
things in this patch...
...unless of course the atomics fallbacks in this patch are
sufficiently sucky that anyone who ends up using those is going to be
sad. Then the bar is a lot higher. But if that's the case then I
wonder if we're really on the right course here.
> I added the x86 inline assembler because a fair number of buildfarm
> animals use ancient gcc's and because I could easily test it. It's also
> more efficient for gcc < 4.6. I'm not wedded to keeping it.
Hmm. gcc 4.6 is only just over a year old, so if pre-4.6
implementations aren't that good, that's a pretty good argument for
keeping our own implementations around. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
