Re: membar_enter semantics

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Whatever the name is, do you contend that store-before-load/store is
> _useful_?  Can you show why?  And, can you show an architecture where
> it's actually cheaper than membar_sync?

The first two are good questions.  (I don't have an answer to them, but
I haven't had much to say on this thread, either.)

But the third...that looks to me as though there's an implicit "no?
then let's just use membar_sync for those uses".  And that, I maintain,
is a terrible idea: conflating two conceptually distinct operations
just because the one is, at present, most efficiently implemented as
the other - that leads to code that doesn't draw the distinction and
ends up crippled, in at least performance and possibly functionality,
when a use case shows up for which those are _not_ true.

Until and unless there are use cases for store-before-load/store, this
is of no immediate importance.  But, if/when there are, I would very
much prefer to see them represented as distinct operations, even if
they are implemented the same way on all current ports.

Of course, it's possible that's not where you were (possibly not
consciously) going with that, in which case the above is moot, or at
least close to it.

> I would rather avoid introducing a proliferation of membar names,
> because the more there are, the more confusing the choice is.

True, but I think the code - and the coders - would benefit from
thinking enough to get it right rather than just shrugging and
resorting to a sledgehammer in all cases.  Consider where we'd be today
if everyone had used a full memory barrier in all cases: all uses would
need inspecting to see what kind of barrier they actually need...or
forget it and eat the performance cost of an often much stricter
barrier than necessary.

> Having nicely paired names helps: if you see `membar_exit', that's a
> hint you should see a corresponding `membar_enter' -- and if you
> don't, that should raise alarm bells in your head.

True, but I also think that having names like that assumes things about
their uses that are not necessarily valid.  At a past job, I had
occasion to write code that called for memory barriers - and I found
myself resorting to looking at what the hardware in question provided
and choosing from those, because none of the higher-level calls
available matched my use case well enough for me to be confident they
were right.  (It was part of a turnkey system, so assuming what the
underlying hardware was was more reasonable than it is for NetBSD.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B