On Sun, Nov 17, 2019 at 02:35:43PM +0000, Mindaugas Rasiukevicius wrote:
> David Holland <dholland-tech%netbsd.org@localhost> wrote:
> > > I see the potential source of confusion, but just think about: what
> > > could "atomic" possibly mean for loads or stores? A load is just a
> > > load, there is no RMW cycle, conceptually; inter-locking the operation
> > > does not make sense. For anybody who attempts to reason about this,
> > > it should not be too confusing, plus there are man pages.
> >
> > ...that it's not torn.
> >
> > As far as names... there are increasingly many slightly different
> > types of atomic and semiatomic operations.
> >
> > I think it would be helpful if someone came up with a comprehensive
> > naming scheme for all of them (including ones we don't currently have
> > that we're moderately likely to end up with later...)
>
> Yes, the meaning of "atomic" has different flavours and describes different
> set of properties in different fields (operating systems vs databases vs
> distributed systems vs ...) and, as we can see, even within the fields.
>
> Perhaps not ideal, but "atomic loads/stores" and "relaxed" are already the
> dominant terms.
Yes, but "relaxed" means something else... let me be clearer since I
wasn't before: I would expect e.g. atomic_inc_32_relaxed() to be
distinguished from atomic_inc_32() or maybe atomic_inc_32_ordered() by
whether or not multiple instances of it are globally ordered, not by
whether or not it's actually atomic relative to other cpus.
Checking the prior messages indicates we aren't currently talking
about atomic_inc_32_relaxed() but only about atomic_load_32_relaxed()
and atomic_store_32_relaxed(), which would be used together to
generate a local counter. This is less misleading, but I'm still not
convinced it's a good choice of names given that we might reasonably
later on want to have atomic_inc_32_relaxed() and
atomic_inc_32_ordered() that differ as above.
> I think it is pointless to attempt to reinvent the wheel
> here. It is terminology used by C11 (and C++11) and accepted by various
> technical literature and, at this point, by academia (if you look at the
> recent papers on memory models -- it's pretty much settled). These terms
> are not too bad; it could be worse; and this bit is certainly not the worst
> part of C11. So, I would just move on.
Is it settled? My experience with the academic literature has been
that everyone uses their own terminology and the same words are
routinely found to have subtly different meanings from one paper to
the next and occasionally even within the same paper. :-/ But I
haven't been paying much attention lately due to being preoccupied
with other things.