<br><br><div class="gmail_quote">On Thu, Nov 8, 2012 at 1:08 AM, Jean-Daniel Dupas <span dir="ltr"><<a href="mailto:devlists@shadowlab.org" target="_blank">devlists@shadowlab.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div>Le 7 nov. 2012 à 21:16, Matthieu Monrocq <<a href="mailto:matthieu.monrocq@gmail.com" target="_blank">matthieu.monrocq@gmail.com</a>> a écrit :</div><br><blockquote type="cite">
<br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 12:47 AM, Seth Cantrell <span dir="ltr"><<a href="mailto:seth.cantrell@gmail.com" target="_blank">seth.cantrell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Nov 6, 2012, at 4:04 AM, Jean-Daniel Dupas <<a href="mailto:devlists@shadowlab.org" target="_blank">devlists@shadowlab.org</a>> wrote:<br>
<br>
><br>
> Le 6 nov. 2012 à 01:37, James Gregurich <<a href="mailto:bayoubengal@me.com" target="_blank">bayoubengal@me.com</a>> a écrit :<br>
><br>
>> hi.<br>
>><br>
>> I just updated to Xcode 4.6.  I note the following:<br>
>><br>
>><br>
>> $ /Applications/Xcode46-DP1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version<br>
>> Apple clang version 4.2 (tags/Apple/clang-424.0.11) (based on LLVM 3.2svn)<br>
>> Target: x86_64-apple-darwin12.2.0<br>
>> Thread model: posix<br>
>><br>
>><br>
>> It is my understanding from the release notes, that LLVM 3.2 is support thread-local storage. I just re-ran my test using the '__thread' keyword from the last time I asked about this and I still just get one instance of the object rather than one-per-thread.<br>


<div>><br>
><br>
> The __thread keyword is a C extension (it not part of the standard). Using it with C++ as is even less specified than using it with C.<br>
><br>
</div><div>> Moreover, it has already be specified in the previous discussion that supporting C++ TLS required OS support. Updating Xcode does not change that.<br>
><br>
<br>
</div>gcc 4.8 now implements thread_local with a performance penalty for global thread_local variables: <a href="http://gcc.gnu.org/gcc-4.8/changes.html#cxx" target="_blank">http://gcc.gnu.org/gcc-4.8/changes.html#cxx</a><br>


<br>
I guess that function-local thread_local variables can use the same scheme for initialization as function-local static variables</blockquote><div><br><br>I would be very interested to know what this "penalty" is. I have a couple idea of what it *could* be, but no idea about what it really is.<br>

<br></div></div></blockquote><div><br></div><div>Actually it look like GCC converts thread_local access into function call with lazy initialization of thread_local variable.</div><div><br></div><div><a href="http://stackoverflow.com/questions/13106049/c11-gcc-4-8-thread-local-performance-penalty" target="_blank">http://stackoverflow.com/questions/13106049/c11-gcc-4-8-thread-local-performance-penalty</a> (especially the third answer that was post after your last comment on this same page)</div>
<div><br></div><div>There is 2 things I would like to know though; How does it handle destruction at the end of the thread, and why it can't avoid the access penalty for POD and base types. The compiler should be smart enough to detect what type require complex access, and what type support direct access.</div>
<br><blockquote type="cite"><div class="gmail_quote"><div>-- Matthieu <br></div></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><div>
<span style="border-collapse:separate;border-spacing:0px"><div>-- Jean-Daniel</div><div></div></span></div></font></span></div></blockquote><div> <font color="#888888"><br><font color="#000000">Thanks!<br><br>I had not seen Kenny's answer, glad someone finally had more than an educated guess to present.<br>
<br>Regarding the penalty for simple POD construction, unfortunately it might not be trivial. For a `static thread_local` it's quite obvious whether the value can be computed right off the bat or not, however for an `extern thread_local` the initializer is invisible, so the optimization is not possible.<br>
<br>Regarding destructors, I don't see how it could be supported.<br><br>All in all I would have preferred that they went with a similar scheme to C++ globals by having a function for initialization and another for destruction called upon entry and destruction. Furthermore it's unclear to me what interactions this have with the `std::async` deferred policy. With the implementation being able to use a thread pool under the hood, this would require recycling the thread_local variables... and I doubt it's covered.<br>
<br>-- Matthieu<br></font></font></div></div>