Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Nov 2015 04:21:37 -0800
From:      David Chisnall <theraven@FreeBSD.org>
To:        Mateusz Guzik <mjguzik@gmail.com>
Cc:        Ian Lepore <ian@freebsd.org>, John Baldwin <jhb@freebsd.org>, Adrian Chadd <adrian.chadd@gmail.com>, freebsd-current <freebsd-current@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>
Subject:   Re: [PATCH] microoptimize by trying to avoid locking a locked mutex
Message-ID:  <5972A132-1589-4230-A3B4-74D2FD442331@FreeBSD.org>
In-Reply-To: <20151106005524.GA4877@dft-labs.eu>
References:  <20151104233218.GA27709@dft-labs.eu> <20151105192623.GB27709@dft-labs.eu> <CAJ-VmonnH4JJg0XqX1SoBXBa%2B9Xfmk%2BHFv58ETaQ9v1-uAAhdQ@mail.gmail.com> <1563180.x0Z3Ou4xid@ralph.baldwin.cx> <1446766522.91534.412.camel@freebsd.org> <20151106005524.GA4877@dft-labs.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Nov 2015, at 16:55, Mateusz Guzik <mjguzik@gmail.com> wrote:
>=20
>> Will that cause problems, especially for code inside a loop
>> where the compiler may decide to shuffle things around?
>>=20
>=20
> Lock value is volatile, so the compiler should not screw us up.

Note: volatile means do not reorder loads/stores *to this value*, the =
compiler is completely free to reorder loads/stores to other values =
around this one.  _Atomic exists in C11 to do the right thing when you =
want to enforce stricter barriers.  In this case, we=E2=80=99re =
currently relying on the compiler not being able to see through the =
assembly.

At some point in the future, I imagine that we=E2=80=99ll move to using =
C11 atomic operations, which will allow the compiler more freedom.  The =
new reads that you=E2=80=99re currently doing should be replaced by =
explicit atomic reads with a relaxed memory order (to enforce atomicity =
with respect to that variable).  If we were to replace the mtx_lock =
field with an _Atomic variant, then the current code would make it a =
sequentially consistent read, which would add a lot of extra overhead.  =
Note also that it is undefined behaviour in C11 to do atomic and =
non-atomic accesses to the same underlying memory location.  Please =
consider the future maintainability of the code when making this change.

David




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5972A132-1589-4230-A3B4-74D2FD442331>