Re: Latches with weak memory ordering (Re: max_wal_senders must die)

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That's really entirely the wrong way to think about it.  You need
>> a fence primitive, full stop.  It's a sequence point, not an
>> operation in itself.

> I was taking it to mean something similar to the memory guarantees
> around synchronized blocks in Java.  At the start of a synchronized
> block you discard any cached data which you've previously read from
> or written to main memory, and must read everything fresh from that
> point.  At the end of a synchronized block you must write any
> locally written values to main memory, although you retain them in
> your thread-local cache for possible re-use.

That is basically the model that we have implemented in the spinlock
primitives: taking a spinlock corresponds to starting a "synchronized
block" and releasing the spinlock ends it.  On processors that need
it, the spinlock macros include memory fence instructions that implement
the above semantics.

However, for lock-free interactions I think this model isn't terribly
helpful: it's not clear what is "inside" and what is "outside" the sync
block, and forcing your code into that model doesn't improve either
clarity or performance.  What you typically need is a guarantee about
the order in which writes become visible.  To give a concrete example,
the sinval bug I was mentioning earlier boiled down to assuming that a
write into an element of the sinval message array would become visible
to other processors before the change of the last-message pointer
variable became visible to them.  Without a fence instruction, that
doesn't hold on WMO processors, and so they were able to fetch a stale
message value.  In some cases you also need to guarantee the order of
reads.
        regards, tom lane