[Mesa-dev] [PATCH] gallium/os: add os_wait_until_zero

[Patrick Baggett]

On Fri, Jun 26, 2015 at 11:40 AM, Marek Olšák <maraeo at gmail.com> wrote:

> If p_atomic_read is fine, then this patch is fine too. So you're
> telling that this should work:
>
> while (p_atomic_read(var));
>
> I wouldn't be concerned about a memory barrier. This is only 1 int, so
> it should make its way into the shared cache eventually.
>
>
Yes, it does make it to the shared cache, but the assumption is that the
compiler will actually generate code to check the memory location more than
one. I've personally been bitten by this assumption - it's a bad one. Ilia
is right. If you have a variable that doesn't appear to modified at all,
but you, the programmer know it will be modified by another thread, you're
asking for an infinite loop. The only guarantee you get is that if this
code ran in isolation on a single thread, it will do what you told it to.
Consider even a trivial transformation:

while(1) {

    if(var == 0) break;

}

The compiler can optimize this to a single statement:

if(var != 0) infinite_loop();

...because it produces the same results as the above code when run in
isolation. However, if 'var' is volilate, it cannot assume that the value
will remain the same and cannot apply this "optimization". What's more fun
is that debug mode tends to not apply these sorts of optimizations, so your
code hangs in release builds, and when you check the memory location, you
can see that it has been updated. Commence tearing hair out. Then you look
at the assembly and hit your head on the desk. Or something like that. ;)

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150626/ddc7e257/attachment.html>