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

On Tue, Sep 1, 2015 at 2:54 PM, Andres Freund <andres@anarazel.de> wrote:
> 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.

Hmm, true.  I think that stuff is probably missing some barriers that
are technically required even on mainstream platforms.  But the races
are narrow, so you may not see any problem in practice, and if you do,
the worst that'll happen is some junk in pg_stat_activity.

>> 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'm just saying that, we're arguing that we can't do it, but they're
doing it, so presumably we could find a way if we were really
determined.  I'm not saying that it's a good use of time, but Linux
seems to think it is.

>> 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 don't know what a "perdiod" is.

>> 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.

If all of your concurrency control looks like this:

SpinLockAcquire(&mutex);  // barrier
// do stuff
SpinLockRelease(&mutex); // also a barrier

...then I think it doesn't matter what wonky stuff Alpha does.  Mutual
exclusion is mutual exclusion, full stop.  When you start doing things
that use pg_atomic_uint32, or, as you mention, the st_changecount
protocol, you are now potentially relying on memory-ordering semantics
that may vary among platforms.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company