On 2013-11-06 17:47:45 +0200, Ants Aasma wrote:
> On Wed, Nov 6, 2013 at 4:54 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > FWIW, I find the requirement for atomic_init() really, really
> > annoying. Not that that will change anything ;)
>
> Me too, but I guess this allows them to emulate atomics on platforms
> that don't have native support. Whether that is a good idea is a
> separate question.
Since static initialization is supported that would require quite some
dirty hacks, but well, we're talking about compiler makers ;)
> > I don't think there really exist any interesting ones? I am using my
> > lwlock reimplementation as a testbed so far.
>
> BufferDesc management in src/backend/storage/buffer/bufmgr.c.
> The unlocked reads that are done from various procarray variables.
> The XLogCtl accesses in xlog.c.
Those are actually only modified under spinlocks afair, so there isn't
too much interesting happening. But yes, it'd be better if we used more
explicit means to manipulate/query them.
> The seqlock like thing used to provide consistent reads from
> PgBackendStatus src/backend/postmaster/pgstat.c (this code looks like
> it's broken on weakly ordered machines)
Whoa. Never noticed that bit. The consequences of races are quite low,
but still...
> IMO the volatile keyword should be confined to the code actually
> implementing atomics, locking. The "use volatile pointer to prevent
> code rearrangement" comment is evil. If there are data races in the
> code, they need comments pointing this out and probably memory
> barriers too. If there are no data races, then the volatile
> declaration is useless and a pessimization. Currently it's more of a
> catch all "here be dragons" declaration for data structures.
Agreed. But I don't think we can replace them all at once. Or well, I
won't ;)
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services