[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 #9 from Uli Schlachter <psychon at znc.in> ---
> My colleague and me discussed it for quite a while, as it was not obvious at the first glance. The conclusion was that it should be ok. If for whatever reason it is not True after we read it, all the following reads/writes to it are atomic, so we should be fine.

(Disclaimer: I have never actually used C11 atomics and I certainly am no
expert on them, I just 'read some stuff')

The only formal semantics for this kind of thing are C11 atomics (right?).
There, you may never read an atomic variable non-atomicly (you are not even
guaranteed to read a value that was written, it might be some intermediate
garbage). Thus, this would at least need to be a relaxed atomic.
However, a relaxed read is too weak: It is allowed to read the new value for
the atomic variable, but continue to read other older memory for other
locations. I.e. it is allowed that the current thread sees that initialisation
was done, but does not see the actual memory stores of the initialisation (and
AFAIK there are architectures were this can actually happen).
Thus, in C11 semantics, this needs at least an acquire read (I'll ignore
consume here, everyone else does) (and the memory store that sets the atomic
variable needs to be at least a release store).

Now, cairo does not use C11 atomic operations (yet). However, the C11 semantics
are the way they are since there are architectures that allow such behaviour.
Thus, something needs to be atomic here.

So, short version: I disagree with the above and I think that this needs a
_cairo_atomic_int_get.

(Also: +1 for Adrian's proposed name change)

-- 
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/20171007/8803f841/attachment-0001.html>