Re: membar_enter semantics

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

On Fri, Feb 11, 2022 at 01:33:04PM +0000, Taylor R Campbell wrote:
 > membar_enter is currently documented to be a store-before-load/store
 > barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
 > 
 >      membar_enter()
 >            Any store preceding membar_enter() will happen before all memory
 >            operations following it.
 > 
 > [...]

This problem (and others like it) are primarily caused by using silly
names like "enter" and "exit" that don't mean anything. (That is: you
could redefine enter to be any-before-any and exit to be
read-before-read and it still wouldn't be obviously wrong to most
people.)

In general, things should be named by what they do, not by the
context in which you're supposed to use them according to some
cookbook thinking-averse approach.

In this case I would argue that the names should be membar_load_any()
and membar_any_store(). I see the argument about matching pairs and
the virtue of it being easy to tell which pairs match, but I don't
think that's outweighed by understanding what the operations actually
*do*, and mucking with this stuff without understanding is virtually
guaranteed to fail.

I will grant that "acquire" and "release" in this context have gained
enough standalone barrier-related meaning that it might be ok to use
those instead of the purely descriptive names (though I'd still prefer
#define membar_acquire() membar_load_any() for that so it's still
clear what's going on with a glance at the header)... but "enter" and
"exit" mean nothing except for a vague association with our mutex ops.

Can we please rename them? Since that's a big job, it's reasonable to
begin by tidying the implementation and leaving the old names
available for compatibility.

 >   Exception: riscv membar_enter is  fence w,rw  ...but I'm not sure
 >   the code we have in riscv matters at the moment -- as far as I know
 >   a working userland hasn't gone out in any release yet.

Indeed, it hasn't. It is safe to just change that.

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