Re: Freezing without write I/O

Just found this in my drafts folder. Sorry for the late response.

On Fri, Sep 20, 2013 at 3:32 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

I have to retract my proposal to try to emulate C11 atomics in C89. I
guess this goes to show why one shouldn't try to conjure up atomic
API's at 2AM. I forgot the fact that while acquire-release semantics
are enough to ensure sequentially consistent behavior, the actual
barriers need to be paired with specific atomic accesses to achieve
that. It's not possible to use freestanding acquire/release barriers
to do implement this, nor would it be possible to include barriers in
the atomic accesses themselves without causing significant
pessimization.

Sequentially consistency (along with causal transitivity and total
store ordering that come with it) should be regarded as a goal. I'm
not able to reason about concurrent programs without those guarantees,
and I suspect no one else is either. Sequential consistency is
guaranteed if atomic variables (including locks) are accessed with
appropriate acquire and release semantics. We just need to use a
hodge-podge of read/write/full barriers and volatile memory accesses
to actually implement the semantics until some distant future date
where we can start relying on compilers getting it right.

I still think we should have a macro for the volatile memory accesses.
As a rule, each one of those needs a memory barrier, and if we
consolidate them, or optimize them out, the considerations why this is
safe should be explained in a comment. Race prone memory accesses
should stick out like a sore thumb.

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

+1. The commits that you showed fixing issues in this area show quite
well why this is a good idea.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de