[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1416732543.16006.381.camel@eris.loria.fr>
Date: Sun, 23 Nov 2014 09:49:03 +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
Hello,
Am Samstag, den 22.11.2014, 20:43 -0500 schrieb Rich Felker:
> On Sun, Nov 23, 2014 at 02:31:35AM +0100, Jens Gustedt wrote:
> > 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.
>
> I don't get what you mean. To access an atomic object larger than the
> hardware supports, you have to hold a lock for the whole interval of
> reading/writing.
No, why do you think that? If you implement access to a critical
resource through a mutex, you only need one mutex and not several
ones. The association to the whole range of the resource is only
logical.
Basically there are two possibilities to implement lockful atomics on
types that don't support atomics directly. One is to construct a
struct around it that also contains the lock/mutex. It has the
disadvantage that e.g sizeof for the _Atomic type and the underlying
type are different. The second one is to realize the locks in a sort
of hash table as I tried to describe.
gcc chose the table approach, so we are stuck with it.
In the case we have here, we can always assume that the type of the
object that we are protecting is fixed and in particular its size is
fixed. So all threads will see the object with the same size and will
only ask for a lock with the start adress of the object. (Otherwise we
have UB.)
This is why C requires that atomicity is integrated in the type, so
you can't ask for atomic operations of arbitrary objects.
Thinking of it, there might be an unintended loophole in the
standard, due to a difference in _Atomic as a qualifier and as
specifier. The qualifier version seems to permit to be applied to a
struct that itself contains other _Atomic types. This then would not
work with the table approach. I'll investigate.
> This is O(n) in the size of the object.
This would be prohibitive, indeed. Luckily we don't need that, so only
the copy operation is O(n), and not the lock.
> I don't see
> where your ideas about pointers and CAS are coming in.
> > > > 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.
>
> Is a pointer to a variably modified type considered variably modified?
yes
> If so maybe these are affected too...
no, the pointers that can be passed to the atomic "functions" are
always pointers to atomic objects, so they can't be arrays (and so
VLA) themselves, nor can an atomic struct containt a VLA or a pointer
to VLA.
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.
