(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 dholl...@netbsd.org
