Re: Freezing without write I/O

On Thu, Sep 19, 2013 at 6:27 PM, Ants Aasma <ants@cybertec.at> wrote:
> I'm tackling similar issues in my patch. What I'm thinking is that we should
> change our existing supposedly atomic accesses to be more explicit and make
> the API compatible with C11 atomics[1]. For now I think the changes should be
> something like this:
>
> * Have separate typedefs for atomic variants of datatypes (I don't think we
>   have a whole lot of them). With C11 atomics support, this would change to
>
>     typedef _Atomic TransactionId AtomicTransactionId;

What's the point of this?

> * Require that pg_atomic_init(type, var, val) be used to init atomic
>   variables. Initially it would just pass through to assignment, as all
>   supported platforms can do 32bit atomic ops. C11 compatible compilers will
>   delegate to atomic_init().

I don't think this is a bad idea for decoration, but again I'm not
sure how much fundamental value it adds.  If it makes it easier for
people to write code that works in C11 and fails on C89, we lose.

> * Create atomic read and write macros that look something like:
>
>         #define pg_atomic_load(type, var) (*((volatile type*) &(var)))
>
>   and
>
>         #define pg_atomic_store(type, var, val) do { \
>             *((volatile type*) &(var)) = (val); \
>         } while(0)
>
>   C11 would pass through to the compilers implementation with relaxed memory
>   ordering.

Same comment.

> * Rename pg_read_barrier()/pg_write_barrier()/pg_memory_barrier() to
>   pg_acquire_fence()/pg_release_fence()/pg_acq_rel_fence(). Herb Sutter makes
>   a convincing argument why loosening up the barrier semantics is the sane
>   choice here. [2] C11 support can then pass though to atomic_thread_fence().

I am entirely unconvinced that we need this.  Some people use acquire
+ release fences, some people use read + write fences, and there are
all combinations (read-acquire, read-release, read-acquire-release,
write-acquire, write-release, write-acquire-release, both-acquire,
both-release, both-acquire-release).  I think we're going to have
enough trouble deciding between the primitives we already have, let
alone with a whole mess of new ones.  Mistakes will only manifest
themselves on certain platforms and in many cases the races are so
tight that actual failures are very unlikely to be reserved in
regression testing.

Personally, I think the biggest change that would help here is to
mandate that spinlock operations serve as compiler fences.  That would
eliminate the need for scads of volatile references all over the
place.

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