[cairo-bugs] [Bug 103037] Segmentation fault in _cairo_traps_compositor_glyphs

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103037

--- Comment #19 from Bill Spitzak <spitzak at gmail.com> ---
>> 1. Everybody is wrong and the above code can fail on Intel-style processors.

>It can fail if compiler decided to optimize access to "y" and reads it only once before entering the loop.

The problem with that argument is that there are atomic operations inside the
loop, including normal sequential fences. The compiler must re-read 'y' after
the loop contents execute or it is wrong.

The argument *does* hold if you use 'x' instead of 'y', it could read an old x,
then get a new y==1 and think it's copy of x is ok (the loop is not run so it
does not need to re-read x). In practice x is either written to by code inside
the loop, or is pointed to by y, so that it is unlikely for an optimizer to do
this. But this is a good reason to write something to force it not to happen,
like your suggestion:

>while (atomic_load_explicit (&y, memory_order_acquire) != 1) {

That is what I thought would work but quick test reveals that it produces a
sync instruction before the access. Unless I am really confused the sync should
not be necessary, since the worst that could happen is it would get the old
value of y and think x is no good yet even though it is, and correctly-written
code must already handle this. Possibly I need to turn on optimization?

BTW the current code is fine, or the release/aquire version (which seems to
compile to the same thing for me but might be the actual "correct" code). Just
trying to get an answer to this question as I see this all the time and there
is a very strong desire by programmers to make the overhead of run-once code
minimal after it is run the first time, so the temptation to remove the atomic
operation which seems to not be required needs an extremely convincing argument
against it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo-bugs/attachments/20171009/c3e86993/attachment-0001.html>