Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Oct 2014 14:25:10 +0000
From:      Andrew Turner <andrew@fubar.geek.nz>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, Mateusz Guzik <mjguzik@gmail.com>, Konstantin Belousov <kib@freebsd.org>, Alan Cox <alc@rice.edu>
Subject:   Re: atomic ops
Message-ID:  <20141028142510.10a9d3cb@bender.lan>
In-Reply-To: <CAJ-FndCWZt7YwFswt70QvbXA5c8Q_cYME2m3OwHTjCv8Nu3s=Q@mail.gmail.com>
References:  <20141028025222.GA19223@dft-labs.eu> <CAJ-FndCWZt7YwFswt70QvbXA5c8Q_cYME2m3OwHTjCv8Nu3s=Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Oct 2014 14:18:41 +0100
Attilio Rao <attilio@freebsd.org> wrote:

> On Tue, Oct 28, 2014 at 3:52 AM, Mateusz Guzik <mjguzik@gmail.com>
> wrote:
> > As was mentioned sometime ago, our situation related to atomic ops
> > is not ideal.
> >
> > atomic_load_acq_* and atomic_store_rel_* (at least on amd64) provide
> > full memory barriers, which is stronger than needed.
> >
> > Moreover, load is implemented as lock cmpchg on var address, so it
> > is addditionally slower especially when cpus compete.
> 
> I already explained this once privately: fully memory barriers is not
> stronger than needed.
> FreeBSD has a different semantic than Linux. We historically enforce a
> full barrier on _acq() and _rel() rather then just a read and write
> barrier, hence we need a different implementation than Linux.
> There is code that relies on this property, like the locking
> primitives (release a mutex, for instance).

On 32-bit ARM prior to ARMv8 (i.e. all chips we currently support)
there are only full barriers. On both 32 and 64-bit ARMv8 ARM has added
support for load-acquire and store-release atomic instructions. For the
use in atomic instructions we can assume these only operate of the
address passed to them.

It is unlikely we will use them in the 32-bit port however I would like
to know the expected semantics of these atomic functions to make sure
we get them correct in the arm64 port. I have been advised by one of
the ARM Linux kernel maintainers on the problems they have found using
these instructions but have yet to determine what our atomic functions
guarantee.

Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141028142510.10a9d3cb>