<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 11:55 AM, Maarten Lankhorst <span dir="ltr"><<a href="mailto:maarten.lankhorst@canonical.com" target="_blank">maarten.lankhorst@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
<br>
On 25-02-15 18:26, Patrick Baggett wrote:<br>
>><br>
>><br>
>> In general things don't get optimized across function calls, except in<br>
>> case of inlinable functions.<br>
>><br>
>> And for compiler attributes it's the opposite,__attribute__((const)) and<br>
>> __attribute((pure)) can be used to indicate some kind of safety to optimize<br>
>> across functions.<br>
>><br>
>> <a href="https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html</a><br>
>><br>
>> This is true, but LTO increases the compiler's ability to make these sorts<br>
> of optimizations across function calls and even C source file boundaries<br>
> without you needing to explicitly mark functions as such.<br>
</div></div>Even if pthread_mutex_lock was completely inlined there would still be a asm volatile(("" ::: "memory")) in there acting as a complete memory barrier to the compiler.<br></blockquote><div><br></div><div>I agree with your conclusion and I agree then that the patch can stand as-is without any changes I proposed. I don't really think "memory barrier" is the right word though, not that it matters. It's more like "all writes need to finish and all <i>previous reads are</i> <i>invalid</i>". Anyways, you've definitely proven to me that the solution is fine.<br></div><div> <br></div></div></div></div>