This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, i dot palachev at samsung dot com, nd at arm dot com
- Date: Thu, 21 Jan 2016 22:41:55 +0100
- Subject: Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- Authentication-results: sourceware.org; auth=none
- References: <568D5E11 dot 3010301 at arm dot com> <5693D908 dot 8090104 at arm dot com> <5695B7BF dot 7050000 at redhat dot com> <5697BA1F dot 6010801 at arm dot com> <569FE981 dot 7010303 at redhat dot com>
On Wed, 2016-01-20 at 15:09 -0500, Carlos O'Donell wrote:
> Everything we do should be incremental. At each step though we
> might ask ourselves: How do we solve the more global problem
> of getting rid of the load lock?
IMO we should ask that. A better question would probably be to ask why
we need the load lock; the lock is just a tool to implement some
intended high-level synchronization scheme. We want to agree on this
scheme early on, otherwise it will be hard to judge correctness.
Note that it can be a perfectly fine approach to simply want to
implement the atomicity and ordering provided by some critical sections
differently -- but in this specific case, it sounds as if we'd like to
have a lock-less scheme anyway, and the current scheme doesn't work or
is not implemented correctly. Both hint that we should go up in layers
of abstraction and revisit what we actually want.