Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS

[Alexandre Oliva <aoliva at redhat dot com>]

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

> On Tue, 2015-06-09 at 19:19 -0300, Alexandre Oliva wrote:
>> It looks like we could still avoid the lock in tls_get_addr by
>> reorganizing dlopen to choose the offset, initialize and release the
>> static blocks, and only then CAS the offset, failing if l_tls_offset was
>> changed along the way.

> Seems so, based on what you wrote.  And then we'd need the CAS to use
> release MO and the loads that may read-from that CAS to use acquire MO.

*nod*

>> > Remember the loads on tile that got mentioned in a previous discussion
>> > we had?
>> 
>> 'fraid I don't.  Reference?

> I didn't find the email thread after looking for a while.  What I
> remember is that tile had operations that are not truly atomic (IIRC,
> don't necessarily reload a whole cache line from memory, or some such).

Aah, now that rings a bell.  It was in a subthread about what a signal
handler might find when interrupting a memset.

>> Correct and reasonable-for-C11 except for the bold and bald assumption
>> that the a lock operation is not a global acquire.  The compiler is
>> forbidden from removing the second load because of the existence of the
>> lock.  Now, that requirement comes from POSIX, not from the C standard.

> POSIX doesn't guarantee anything about plain memory accesses that do
> have data races, right?  This isn't about the lock itself and whether it
> "synchronizes memory", but about the data race and what the compiler can
> do based on assuming DRF programs.

Since POSIX doesn't specify atomics, I'm inclined to think this
reasoning rules out useful existing practice that is at least arguably
valid under POSIX, but...  I see where this is coming from, and I kind
of like the better-defined semantics, so I can see it could make sense
for POSIX to deprecate this practice and embrace atomics.

>> *if* the abstract machine would have stored something in the variable to
>> begin with.

> No, not generally.  The program must behave as-if executed by the
> virtual machine.  But behavior is defined as all accesses to
> volatile-qualified variables and I/O, so the program is allowed to
> speculatively store if it doesn't affect the volatile / I/O behavior of
> the program.

I'm pretty sure I saw wording to the effect of what I wrote above in
some standard or draft a while ago.  That made sense to me: introducing
stores where there weren't any before seems like a great recipe to
introduce races.

>> > No, this is simply not true in general.  You can argue about likelihood
>> > in this *particular* case, but then you're doing just that.
>> 
>> Indeed, that's just what I'm doing.

> But that's not useful.  First, we want rules that apply and are safe in
> general, not rules that require case-by-case reasoning.  Second, we
> don't want to depend on something being unlikely -- we want the thing to
> always work.

It looks like you assume "argue about likelihood" does not encompass the
case of "argue it's never going to happen", although that is what I was
doing.

I like general rules, but sometimes we have to reason on a case-by-case
basis.  I don't oppose taking advantage of situations that only arise in
specific cases to improve the code.

>> Now that the patch is withdrawn because it is broken, we can even focus
>> on more productive questions and answers about it.  But this only makes
>> sense (as opposed to being a waste of time) if there's a commitment to
>> turn the conversation into proper documentation.  Do we have that from
>> anyone?

> I suppose Carlos and Siddhesh will do that then.

I wouldn't jump to that conclusion.  The broader problem is not related
with TLS, but about rtld's holding a lock while running module
finalizers.

>> rtld that loads and defines the variable and then releases the rtld lock
>> (and thus the memory) happens-before any well-defined use of the
>> variable (without some happens before, how could it safely get ahold of
>> the relocations used in the TLS access model?), even if it doesn't take
>> the rtld lock, as covered in other messages upthread.

> To avoid confusion, I assume you are referring to such a pattern:

> Thread 1:
>   data = 1;
>   flag = 1;
>   unlock;

> Thread 2:
>   if (flag) foo = data;

You're missing the happens-before relationship.  I don't see any in your
example, but I explicitly stated there was one, so your example does not
match at all my attempt summarize what we'd already discussed and agreed
on, namely, rtld's setting up the TLS variable and applying TLS
relocations that reference it, so please refer to that part of the
thread so that we don't go in circles.

> If the necessary happens-before is ensured through other sync, then
> we're good though.

That was the conclusion upthread.  Do you see any reason to revisit it
after rereading it?

>> > We implement POSIX for users of glibc, but we do not implement on top of
>> > POSIX inside of glibc

>> Is this documented anywhere?

> https://sourceware.org/glibc/wiki/Concurrency
> says that we're using the C11 memory model.

Well, that's not exactly a true statement ATM.  We are *aiming* at it,
but there are tons of code in GNU libc that aren't quite there yet.


> Thus, there will be synchronizes-with (and thus happens-before) edges
> between a release of a particular mutex instance and a subsequent
> acquisition of the *same* mutex instance.   This creates a total order
> on each particular mutex instance, but there is no happens-before
> enforces with unrelated release or acquire operations (e.g., on
> different mutex instances, atomics, ...).

... because those don't introduce a synchronization with the release
sequence that precedes releasing that specific mutex, whereas a memory
fence would have more pervasive synchronization effects.  Is this what
you meant with "In C11, there's a distinction between a release-MO fence
and a mutex unlock operation (i.e., a release-MO store)"?  Is this all
you meant?

-- 
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