From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6595 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1 Date: Sat, 22 Nov 2014 20:43:54 -0500 Message-ID: <20141123014354.GF29621@brightrain.aerifal.cx> References: <386bdfe0.dNq.dMV.22.ce88IE@mailjet.com> <1415553117.2457.1250.camel@eris.loria.fr> <28e7e26d.dNq.dMV.24.cxrFKH@mailjet.com> <1416697795.16006.338.camel@eris.loria.fr> <20141122233022.GE29621@brightrain.aerifal.cx> <1416706295.16006.354.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416707056 23594 80.91.229.3 (23 Nov 2014 01:44:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2014 01:44:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6608-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 23 02:44:09 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XsMDh-0005fg-4B for gllmg-musl@m.gmane.org; Sun, 23 Nov 2014 02:44:09 +0100 Original-Received: (qmail 17859 invoked by uid 550); 23 Nov 2014 01:44:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17842 invoked from network); 23 Nov 2014 01:44:07 -0000 Content-Disposition: inline In-Reply-To: <1416706295.16006.354.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6595 Archived-At: On Sun, Nov 23, 2014 at 02:31:35AM +0100, Jens Gustedt wrote: > 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. 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. This is O(n) in the size of the object. 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? If so maybe these are affected too... > > > > 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++. Yes. > The ifdef is a single one to switch between _Bool or unsigned char or > so. Yes, but I think the #ifdef always comes out one way anyway, though I don't remember which one and don't have the file in front of me. Rich