This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Optimize generic spinlock code and use C11 like atomic macros.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 13 Apr 2017 18:36:03 +0200
- Subject: Re: [PATCH 1/2] Optimize generic spinlock code and use C11 like atomic macros.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=triegel at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E19B18047C
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E19B18047C
- References: <1481905917-15654-1-git-send-email-stli@linux.vnet.ibm.com> <5857CF10.1060100@arm.com> <628f6311-239c-5eea-572c-c2acae6fcbee@linux.vnet.ibm.com> <1487017743.16322.80.camel@redhat.com> <60a34645-17e4-6693-1343-03c55b0c47ad@linux.vnet.ibm.com> <1487437038.20203.68.camel@redhat.com> <25ad863b-6f20-bfb7-95e6-3b04a2b3eee8@linux.vnet.ibm.com> <1487598702.20203.138.camel@redhat.com> <b57d3477-a041-7b06-82ac-6d2b6c6bb08c@linux.vnet.ibm.com> <1491487245.5374.161.camel@redhat.com> <09ae8ea7-4119-76c1-cd58-36cbdf587390@linux.vnet.ibm.com> <mvmmvbod6cj.fsf@suse.de> <97d9d43a-0bf1-7e93-6985-97d603c96844@linux.vnet.ibm.com> <mvmefx0crkq.fsf@suse.de> <8567ee67-0785-aba5-5f13-0168b252cfee@linux.vnet.ibm.com>
On Tue, 2017-04-11 at 09:06 +0200, Stefan Liebler wrote:
> On 04/10/2017 03:36 PM, Andreas Schwab wrote:
> > On Apr 10 2017, Stefan Liebler <stli@linux.vnet.ibm.com> wrote:
> >
> >> On 04/10/2017 10:17 AM, Andreas Schwab wrote:
> >>> On Apr 07 2017, Stefan Liebler <stli@linux.vnet.ibm.com> wrote:
> >>>
> >>>> /* ATOMIC_EXCHANGE_USES_CAS is equal to 1 if atomic_exchange operations
> >>>
> >>> Why 1 exactly, and not just non-zero?
> >>>
> >>> Andreas.
> >>>
> >>
> >> This points out that there is only a true/false choice and
> >> all architectures have to define it.
> >
> > That doesn't answer my question. Why do you need the dance of checking
> > for 1 explicitly?
> >
> > Andreas.
> >
> At the moment there is only a choice between 0 and 1.
This is fine. There is no reason to allow a different value even if
this is just a boolean.
> The check ensures that ATOMIC_EXCHANGE_USES_CAS is defined and it has a
> specific value.
> If someone defines it to another value, he will get an error here.
> Then the check and the comment is hopefully updated, too.
The comments make it clear that it has to be 0 or 1, and can be used
without explicitly checking the value.
We can add the explicit check once, as you did in atomic.h, but I don't
think it's neither required nor a bad thing to do.