Date: Sun, 23 Nov 2014 10:06:39 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1 On Sun, Nov 23, 2014 at 09:49:03AM +0100, Jens Gustedt wrote: > 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. I think my statement was just unclear. I don't mean that the lock has to be associated with the whole interval in memory. I mean the lock has to be held for the whole interval in time. This makes it clear that a spinlock is not appropriate even if you don't have the deadlock issue to worry about from priority scheduling. > 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. Accessing individual members of atomic structs is UB last I checked. IMO it's rather stupid that the standard allowed atomic structs anyway, but we're stuck with them. > > 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. O(n) time the lock is held, not O(n) time obtaining locks. Sorry. > > I don't see > > where your ideas about pointers and CAS are coming in. I'm still confused about this. > > > > > 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. _Atomic int (*pmat)[n]; Then &pmat is a pointer to a valid atomic type, an atomic pointer to a VLA type. Rich
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.