This is the mail archive of the libc-alpha@sourceware.org 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: [PR18457] Don't require rtld lock to compute DTV addr for static TLS


On Jun  9, 2015, Torvald Riegel <triegel@redhat.com> wrote:

> On Mon, 2015-06-08 at 23:30 -0300, Alexandre Oliva wrote:
>> On Jun  7, 2015, Torvald Riegel <triegel@redhat.com> wrote:

>> > Also, it sounds as if any thread concurrent with the dlopen could only
>> > actually create a concurrent access if dlopen has the lock already --
>> > but that doesn't seem to be a requirement based on the "spin"
>> > example/analogy you gave.
>> 
>> There are two roles dlopen plays here:
>> 
>> 1. loading the module that defines the TLS variable
>> 
>> 2. applying TLS replications to modules that reference the TLS variable
>> 
>> It might turn out that 1. and 2. are performed under a single rtld lock
>> taking, and a subsequent dlopen could bring in additional references to
>> TLS variables.

> I can't follow you; I don't see how it addresses my comment.

rtld's role 1 is analogous to init in the electron spin example.

rtld's role 2 is analogous to make_positive in the electron spin
example.

In some cases, rtld roles 1 and 2 are performed without releasing the
lock.  In this case, no concurrent accesses are possible, because nobody
else can have the pointer returned by init, to pass to the other
functions, before init returns.

Now, in case rtld's role 2 is performed separately, as in a subsequent
dlopen (analogous to make_positive), there may be concurrent
tls_get_addr accesses (analogous to concurrent positive_p calls).  At
this point, role 1 has already released the lock and set up the module
defining the TLS variable and possibly processed some dynamic TLS access
model relocations (analogous to init returning), so there is room for
concurrency between those accesses and a subsequent dlopen, that may or
may not require the variable to be placed in static TLS.

Does this clarify how my response addresses your comment?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


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