[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1416706295.16006.354.camel@eris.loria.fr>
Date: Sun, 23 Nov 2014 02:31:35 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1
Hi Rich,
Am Samstag, den 22.11.2014, 18:30 -0500 schrieb Rich Felker:
> atomic_flag is not viable for this because it does not have a
> wait/wake mechanism. You'd be spinning, which means in processes with
> different priorities involved, you could easily get deadlock if the
> lower-priority thread got suspended while holding the lock. You really
> do need mutexes.
I am probably still too much thinking in C11, only, which doesn't have
the notion of priorities.
Actually, I think a specially cooked synchronization tool would be
better. Something that combines an atomic pointer (to point to the
object) with a futex living on it for the waiting. This would probably
be a bit more challenging to implement, but here we really have an
interest to have the fast path really fast, just one CAS of the
pointer.
> > What has all of this to do with VLA? I am lost.
>
> The operands of __typeof__ and sizeof get evaluated when they have VLA
> type. I think this is the problem.
ah, ok
No, this isn't a problem, I think. Arrays aren't allowed to be subject
of an _Atomic qualification (arrays are never qualified
themselves). For _Atomic type, the standard explicitly excludes
arrays. So arrays in general and VLA in particular should never be
passed as such into any of these generic functions, only pointers to
atomic objects can.
> > > I have changed it to be an atomic_bool in a struct as both GCC and Clang
> > > has it in a struct. Presumably to separate it from the generic _Atomic
> > > stuff.
> >
> > Again, since we want to have ABI compatibility, it is not your choice
> > to make. You'd simply have to stick to the choice that gcc made. So
> > you have to copy the declaration of the struct, including all the
> > ifdef fuzz.
>
> I'd have to look at it again, but IIRC only one case of the #ifdef
> mess was actually possible. The others were for hypothetical archs
> without real atomics which we can't support anyway.
We should have it as a struct, if the implementations have it like
that, I think:
- It should have same alignment properties for ABI compatibility.
- It should lead to the same typename when included in C++.
The ifdef is a single one to switch between _Bool or unsigned char or
so.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
