Re: 9.4 broken on alpha - Mailing list pgsql-hackers

On 2015-09-01 14:40:36 -0400, Robert Haas wrote:
> I doubt there is a big problem with supporting Alpha apart from
> lock-free algorithms.

Note that we've had lock-free algorithms for years. E.g. the changecount
stuff in pgstat.c.

> The best argument for continuing to support Alpha is probably that
> Linux does.

Not sure why that's an argument? I mean linux supports architectures
without an MMU, but we'll surely never?

> I don't know how they do that.  Presumably most Linux
> kernel developers don't have access to Alpha hardware, which makes me
> wonder how they avoid missing read_barrier_depends() in places where
> it is needed (since it's a no-op everywhere else).

I think they do miss it regularly from what I'm skimming on these lists.

> Considering that Linux's use of lock-free algorithms is vastly more
> extensive than ours, it would seem awfully difficult to avoid
> introducing bugs of that type.

In a lot of cases they've embedded the read_barrier_depends() in
macros. E.g. when doing concurrent stuff involving rcu you're only ever
supposed to dereference memory using rcu_dereference() which on moset
architectures is just a volatile cast to force a read from memory, but
includes a smp_read_barrier_depends(). There's a bunch of other similar
cases.

> I previously argued that, rather than changing lwlock.c to use atomics
> categorically (and falling back to atomics emulation when real atomics
> are not available), we should have two implementations, one based on
> atomics and the other relying only on spinlocks.

I still think that'd have been a utter horrible mistake. lwlock.c is
already complicated enough. That it actually ends up being faster when
implemented using atomics implementation rather than spinlocks over the
full perdiod doesn't hurt either.

> I believe if we'd done that, we would be in a position to continue
> supporting Alpha and whatever other weird stuff comes up in the
> future, because, again, I think lock-based algorithms should be solid
> everywhere.  Once we didn't take that path, I think the die was cast.

I'm not following how those are related - the relevant pointer chasing
in lwlock.c should actually be safe on alpha (as done under a
spinlock). And whether lwlocks is implemented primarily using spinlocks
or atomics doesn't have a bearing on the data dependency barriers? There
might be a data dependency missing somewhere, but ...?

Since alpha has easy to use atomics support it'd actually have ended up
using the gcc generics and used the atomics implementation anyway.

Greetings,

Andres Freund