Re: Deduplicating atomics written in terms of CAS

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

Am Sonntag, den 17.05.2015, 02:14 -0400 schrieb Rich Felker:
> - a_and_64/a_or_64 (malloc only; these are misnamed too)

I should have checked the use before my last mail. They are
definitively misnamed.

Both uses of them look ok concerning atomicity, only one of the a_and
or a_or calls triggers.

The only object (mal.binmap) to which this is applied is in fact
volatile, so it must actually be reloaded all the time it is used.

But in line 352 the code uses another assumption, then, that 64 bit
loads always are atomic. I don't see why this should hold in general.

We already have a similar assumption for 32 bit int all over the
place, and I am not too happy with such "silent" assumption. For 64
bit, this assumption looks wrong to me.

I would be much happier by using explicit atomic types and atomic load
functions or macros everywhere. For normal builds these could be dummy
types made to resolve to the actual code that we have, now. But this
would allow to have hardening builds, that check for consistency of
all atomic accesses.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]