From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6596 Path: news.gmane.org!not-for-mail From: Joakim Sindholt Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1 Date: Sun, 23 Nov 2014 02:47:12 +0100 Message-ID: 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> <20141123014354.GF29621@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1416709780 27724 80.91.229.3 (23 Nov 2014 02:29:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2014 02:29:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6609-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 23 03:29:34 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 1XsMve-0000Xx-KM for gllmg-musl@m.gmane.org; Sun, 23 Nov 2014 03:29:34 +0100 Original-Received: (qmail 9784 invoked by uid 550); 23 Nov 2014 02:29:33 -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 19839 invoked from network); 23 Nov 2014 01:47:24 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; q=dns/txt; d=zhasha.com; i=opensource@zhasha.com; s=mailjet; h=domainkey-signature:message-id:mime-version:content-transfer-encoding:content-type:from:to:subject:date:in-reply-to:references:list-unsubscribe; bh=M2l7MTcykERI73trSxDljGgfi2k=; b=0vXJuzRc6zecINS5+kGvWz/LFHQVlev823TyNWtbYW3lx1Uk6FyUITHJ20ekZ+zI9ZRzYmSWlJs8QtuueNliOS0hf34jmoxaM3XGDN7OrQ+rRvQelTEGGPtefg7QUaMFhICoHOdncxRVJzgf+xh/RRvllmUqywsnYN4qtsIOCNc= Domainkey-Signature: a=rsa-sha1; c=simple; q=dns; d=zhasha.com; s=mailjet; h=message-id:mime-version:content-transfer-encoding:content-type:from:to:subject:date:in-reply-to:references:list-unsubscribe; b=xgIb+f/fLk0odR7vqRJHOA4uEP4eJmP1pYfohDDQFIG+7uXy5oSnDuD4MdbRlG9nGWfoGawGWsh0kaY5Ka1cXYo2gcfG1cWDawHwnl6w+tmQjLY4k+rEAQMBc0ViEjQS/PJgPn/+OgHLfB0m5fmvc1KVrJZi3lvJiIZ74tayDlc= In-Reply-To: <20141123014354.GF29621@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6596 Archived-At: On Sat, 2014-11-22 at 20:43 -0500, Rich Felker wrote: > 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. GCC 4.9: typedef _Atomic struct { #if __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1 _Bool __val; #else unsigned char __val; #endif } atomic_flag; Clang 3.6: #ifdef __cplusplus typedef _Atomic(bool) atomic_bool; #else typedef _Atomic(_Bool) atomic_bool; #endif typedef struct atomic_flag { atomic_bool _Value; } atomic_flag;