Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1

[Rich Felker <dalias@libc.org>]

On Sun, Nov 23, 2014 at 06:05:07PM +0100, Jens Gustedt wrote:
> Am Sonntag, den 23.11.2014, 11:38 -0500 schrieb Rich Felker:
> > 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.
> 
> We wouldn't do that, if we'd have a choice, sure. But, if gcc decides
> to use the super-fast TAS that has other values, you'd give up binary
> compatibility?

This is a hypothetical situation that doesn't exist, and since it
doesn't exist now and there's no logical reason for it to be
introduced in the future on new archs, it's not worth adding
complexity over.

Rich