Re: membar_enter semantics

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

On Mon, Feb 14, 2022 at 08:11:57AM +0000, Taylor R Campbell wrote:
 > > 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.)
 > 
 > The problem at hand is that one word in the documentation doesn't
 > reflect
 > 
 > - 15 years of implementation on x86, powerpc, and sparc,
 > - 15 years of usage, or
 > - sensible semantics for real-world use cases.
 > 
 > All the other NetBSD membars meet this -- as would the proposed
 > one-word documentation change.

My point was somewhat different: we ended up in this hole with the
docs having been wrong for who knows how long precisely because the
terminology is rubbish. If the name "membar_enter" meant anything
coherent that anyone could remember, this sentence would have been
obviously wrong.

I'm not arguing that we shouldn't fix this. I'm arguing that we should
deprecate the names "member_enter" and "membar_exit" because they're
failed terminology, and this issue is evidence of that.

 > > 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.
 > 
 > Experience working in an environment where all possible membars are
 > available and named according to {load,store}-before-{load,store}
 > combinations tells me that it doesn't actually improve anything.
 > 
 > Instead, it just encourages people to overthink bad choices locally
 > without thinking about or documenting the two-sided _protocol_ between
 > threads, and then leave nonsensical barriers around because they
 > locally sounded good.

Perhaps so. But that beats people jumping to conclusions and using the
wrong things because they don't understand what they do and think a
semantically null name is telling them something useful.

Also, I'd say it is not about protocols so much as about data
structure invariants. The use of matching pairs is only meaningful in
specific circumstances where there's one writer and one reader, and
while one writer may be a reasonable assumption, IME one reader
often isn't.

And when you're thinking about it in terms of invariants, the exact
operations you're ordering to satisfy the invariant become much easier
to follow.

At a minimum we should deprecate the meaningless names "enter" and
"exit" and replace them with "acquire" and "release", since while the
latter names also don't inherently mean anything they've also got C99
and some years of research literature backing them up.

Meanwhile "producer" and "consumer" are equally meaningless and
equally failed terminology and the best available names are
"write_write" and "read_read". Unless it's the other way around.

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