This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/4] Provide C11 atomic operations

On Wed, 2014-10-29 at 22:20 +0100, Torvald Riegel wrote:
> This patch set provides support for C11-like atomic operations.  It does
> not change existing code that that uses the current atomic ops, so
> callers of atomic ops can be changed one algorithm at a time.  (To
> illustrate such changes, the last patch transforms pthread_once to use
> C11 atomics.)
> The atomic ops all have C11 semantics but use different names to avoid
> naming collisions with C11 operations.  If we should require C11
> compilation at some time in the future, transforming the calls of all
> atomic operations will be easy.
> This expects, of course, that we use the C11 model.  The only difference
> is that I've chosen to not explicitly use atomic types, but rather just
> use atomic operations on plain data types.  This will work for existing
> code that is transformed.  For new code, it can mean that programmers
> have to be careful to use the right alignment if the atomic ops on a
> particular arch come with such constraints.
> If we get consensus for that, we can change to using atomic types in a
> second phase.

I have committed this patch after some more code comparison for x86_64
pthread_once using a current GCC, and a regression check on x86_64.  The
fast path has identical code.  On the slow path, there are some minor
differences in which instructions are used, but I didn't spot anything
hat looked significant.
I've also fixed the Changelog; Adhemerval, thanks for spotting this.

> After acceptance of this patch set, I can provide additional
> documentation on the wiki.  However, I'd like to get some input on how
> much (ie, how much detail, etc.) documentation you would like to see.
> One reason to move to C11 is to not have contributors have to learn
> something new, so I guess that the glibc-specific documentation we'd
> need would be rather small in size.

I've started a draft of guidelines for concurrency in glibc, including
how to document concurrent code, at

These are my opinions, so please have a look and let me know if you
disagree with something or want to see further information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]