From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6605 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: Sun, 23 Nov 2014 11:38:50 -0500 Message-ID: <20141123163849.GL29621@brightrain.aerifal.cx> References: <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> <1416735814.16006.387.camel@eris.loria.fr> <20141123152129.GJ29621@brightrain.aerifal.cx> <1416760143.16006.460.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 1416760752 7963 80.91.229.3 (23 Nov 2014 16:39:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2014 16:39:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6618-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 23 17:39:05 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 1XsaBk-0005hO-AC for gllmg-musl@m.gmane.org; Sun, 23 Nov 2014 17:39:04 +0100 Original-Received: (qmail 27942 invoked by uid 550); 23 Nov 2014 16:39:03 -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 27931 invoked from network); 23 Nov 2014 16:39:02 -0000 Content-Disposition: inline In-Reply-To: <1416760143.16006.460.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:6605 Archived-At: On Sun, Nov 23, 2014 at 05:29:03PM +0100, Jens Gustedt wrote: > > > For the discussion about the second case for the type, this is the > > > question if there are archs that implement TAS operations with other > > > values than 0 for "unset" and 1 for "set". There seem to be archs out > > > there that implement TAS with other values, I vaguely remember having > > > heard about some risk arch (??). Actually this also is the reason why > > > the standard defines this type in such a weird manner, and why per the > > > standard it needs a dedicated initialization macro, default > > > initialization with 0 doesn't do in all cases. > > > > These are not archs we can support with musl, so they wouldn't be > > relevant. And they're not archs that could support POSIX without a > > kernel stop-the-world approach for implementing CAS, or syscalls for > > every synchronization action. > > Could you be more specific? Is it that you know that all the arch in > question and conclude about their behavior from you knowledge about > them? > > Without more specific information I don't see any reason, that an arch > that has such specialized super-fast TAS with weird values couldn't > have a CAS that behaves "normal". But then I also don't see any reason > for such a TAS design in any case ... If you have a CAS, you don't use the broken TAS to implement TAS. You just use the CAS. Rich