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

[IainS <developer at sandoe-acoustics dot co dot uk>]

On 8 Jun 2010, at 18:01, Ralf Wildenhues wrote:

> Hello,
>
> * Paolo Bonzini wrote on Tue, Jun 08, 2010 at 06:31:52PM CEST:
> > > > On 06/06/2010 02:58 PM, IainS wrote:
> > > > > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170).
>
> > I guess it depends on when __emutls_get_address is lowered.  But
> > then the compiler could be smart and "localize" the variable with
> > -fwhole-program, so your change is only safe for current compilers.
> > I think the best solution is to make "a" volatile, like
> >
> > 		__thread volatile int a;
> > -		static int volatile *volatile a_in_other_thread;
> >
> > ...
> >
> > 		int volatile *volatile a_in_main_thread;
> > 		a_in_main_thread = &a;
> >                *a_in_main_thread;
> >
> > This is more future-proof, I guess. Can you try this?
>
> I asked about volatile in the above PR (comment #39), and was called
> down (comment #59).  I've read <http://www.airs.com/blog/archives/ 
> 154>.
>
> Can somebody untie the logical knot up my brain?  Is any of the  
> volatile
> really needed here?  And if yes, can somebody provide an explanation
> that doesn't sound like "let's try if this works"?

the volatile will not work without re-ordering the statements as well  
(which I did not do in my test reported in c #58).

At that stage, we were still 'debugging'  and had not realized the  
origin of the problem.

> Is volatile required here because we want to peek behind  
> implementation
> details that are not supposed to be observable, and observable  
> features
> of threads don't need them?

indeed we need to know what's going on behind - because the access to  
the __thread variable causes an address translation routine to be  
called that allocates memory.  The problem we are trying to solve is  
that the allocated memory can be freed (when the thread completes) and  
then reallocated - causing the apparent failure.

cheers,
Iain