Re: [Patch, toplevel/config] fix tls.m4 configure race condition (bootstrap/PR43170)

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jun 08, 2010 at 09:04:39PM +0200, Ralf Wildenhues wrote:
> * Jakub Jelinek wrote on Tue, Jun 08, 2010 at 08:50:58PM CEST:
> > On Tue, Jun 08, 2010 at 08:27:55PM +0200, Ralf Wildenhues wrote:
> > > So, when we are admitting to the use of volatile as a hack to tame the
> > > optimizer beast, let's turn the question around: does __thread have any
> > > guaranteed observable semantics that we can test instead?  I.e.,
> > > something that doesn't need revisiting with the great optimizing
> > > features of next year's GCC?
> > 
> > The property is that addresses of the __thread variable in different
> > concurrent threads are different (or, in other way, modifying the __thread
> > var in one thread won't modify it in the other thread).
> 
> So, a test that modifies the __thread variable in one thread, gives up a
> mutex, then the other thread grabs it, and looks whether its copy of the
> variable was updated should work without volatile, and regardless of the
> power of your optimizer, and has the additional property of relying only
> on semantics guaranteed by standards.  Right?

No.

At least for __thread vars where the address isn't passed to other threads,
the ___thread var can't be modified by other threads, so if you do
a = 1;
while ... pthread_cond_wait (&c, &m);	/* Make sure other thread runs its criticial section which sets a = 2; */
if (a != 1)
  abort ();
I don't see why smart optimizer couldn't optimize that a != 1 test away.

The test is testing for a bug in old glibcs which was violating the __thread
property, and I believe you really need some optimization barriers for the
test, otherwise some smart optimization in the future will optimize the test
away and let it succeed on buggy old glibcs.

	Jakub