This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andrew Hunter <ahh at google dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 06 Dec 2013 16:48:24 -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> <CADroS=52HBiYZ2UsovxQFHTTWNO6zhk5cznhbe6Rh1YfrZGxEA at mail dot gmail dot com>
On 12/05/2013 03:01 PM, Andrew Hunter wrote:
>> You could use a futex to block until *pp != TLS_DTV_UNALLOCATED. If
>> this is a one-shot transition (ie, like in a latch), then this should be
>> simple and would just need a suitable futex wake operation elsewhere.
>>
>> However, the pure spin-wait is probably fine unless we want to support
>> programs with real-time priorities (ie, where a higher-prio thread could
>> starve a lower-prio thread forever, for example, if the former is
>> spin-waiting for a result produced by the latter). I don't know whether
>> we do or do not want to support that, so I'm leaving that to others to
>> decide.
>>
>
> This case can only occur (I believe) when we have:
>
> dlopen(L1) (contains TLS variable x)
>
> Thread T1 reads x and goes to dynamically initialize it, racing with...
> Thread T2 dlopen(L2) (contains tls reloc referencing x from L1)
>
> which is at best extremely obscure; I would prefer to avoid the
> complexity of futex unless we really see this as a priority.
It is not a priority. We can optimize this in future revisions.
Cheers,
Carlos.