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.