Re: membar_enter semantics

[David Holland <dholland-tech%netbsd.org@localhost>]

(sorry, lost track of this)

On Mon, Feb 14, 2022 at 05:12:13AM +0100, Joerg Sonnenberger wrote:
 > Am Mon, Feb 14, 2022 at 02:45:46AM +0000 schrieb David Holland:
 > > On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote:
 > >  > Am Mon, Feb 14, 2022 at 02:01:13AM +0000 schrieb David Holland:
 > >  > > In this case I would argue that the names should be membar_load_any()
 > >  > > and membar_any_store().
 > >  > 
 > >  > Kind of like with the BUSDMA_* flags, it is not clear from that name in
 > >  > which direction they work either. As in: is it a barrier that stops the
 > >  > next load? Is it a barrier that ensures that a store is visible?
 > > 
 > > Given that English is left-to-right, and that memory barriers are
 > > about ordering memory operations, it seems a lot clearer than "enter".
 > 
 > I don't think that arguments works with the way barriers around read and
 > write operations are normally used. A read barrier is normally "ensure
 > that a read doesn't move before this point", where as write barrier is
 > normally "ensure that a write operation doesn't move beyond this point".
 > Note the opposite temporal direction. Not sure if there are sensible use
 > cases of the inverted directions, i.e. if we care about CPUs that can
 > reorder reads relative to later writes.

I don't follow this argument. The natural interpretation of
"membar_any_store" is "barrier between any and store", so for a "read"
barrier, that is, "membar_read_read", it's a barrier between reads and
reads.

I don't see how the motion direction of the anticipated leakage
applies, and I think getting the anticipated leakage involved in the
naming of the operation is a bad idea. (It would be another example of
naming things after when they're supposed to be used rather than what
they do.)

-- 
David A. Holland
dholland%netbsd.org@localhost