Re: membar_enter semantics
Am Mon, Feb 14, 2022 at 02:45:46AM + 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 + 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. Joerg
Re: membar_enter semantics
On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote: > Am Mon, Feb 14, 2022 at 02:01:13AM + 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". -- David A. Holland dholl...@netbsd.org
Re: membar_enter semantics
Am Mon, Feb 14, 2022 at 02:01:13AM + 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? Joerg
Re: membar_enter semantics
On Fri, Feb 11, 2022 at 01:33:04PM +, 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 dholl...@netbsd.org
