This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Hunter <ahh at google dot com>, libc-alpha at sourceware dot org
- Date: Thu, 28 Nov 2013 20:09:08 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <1380830518-16721-1-git-send-email-ahh at google dot com> <1382477766-15770-1-git-send-email-ahh at google dot com> <Pine dot LNX dot 4 dot 64 dot 1310222145490 dot 13258 at digraph dot polyomino dot org dot uk> <CALoOobMsO6X86JFD4J7F-EL-J+xOTEOVbzH=6mwrvfCnFvw57Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311052233090 dot 30260 at digraph dot polyomino dot org dot uk> <CALoOobM70-mix+=1zuDnSoK7SRqQChbL=03xBkUcFf1fyS1Mjw at mail dot gmail dot com> <CALoOobP7kdpZCZA0a7MZWCtONu81fW4H_qAWOEfpfvzxJgG_=Q at mail dot gmail dot com> <CALoOobP6rTDosadvLKhHY+deDsU-FtvyO8QX_Y4dZy716e2ATQ at mail dot gmail dot com> <1385641717 dot 3152 dot 8418 dot camel at triegel dot csb>
On 11/28/2013 07:28 AM, Torvald Riegel wrote:
> I've looked at the synchronization bits in this patch. Detailed
> comments below, and one general comment:
> Please document the synchronization code you add in more detail. The
> C11 memory model should be the base model, even though the atomic
> operations we currently have are somewhat different.
> In particular, if using barriers / memory orders (MO) such as "_acq",
> please make sure that you document which ordering they are meant to
> achieve. (Or, if there are no such barriers or just relaxed MO, please
> document why we don't need a particular ordering.) For example, if you
> use an acquire barrier / MO, please briefly document with which release
> barriers / MO this is supposed to create happens-before relations.
> Also, the atomic operations that we currently have don't cover all the
> options in the C11 model (for example, we don't have relaxed MO
> read-modify-write ops AFAIR); thus, if you use a glibc atomic operation
> that is stronger than what you'd actually need in the C11 model, please
> document this as well so we can easily change that later on once we
> should have those atomic ops too.
I specifically asked Torvald to review this patch, and in general
I agree with Torvald's review.
As a community we're trying to:
* Document parallelism and concurrency in the source code.
- Lower maintenance burden by documenting enough that we can
relax the barriers later when we have a more expressive internal
API for atomic operations.
* Prepare code for the C11 memory model.
- Try to align new code with the C11 memory model to make it
easier to maintain this code in the future when we move to
All of that means we need a little more documentation in the patch.
Thanks for helping review this patch!