<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Segmentation fault in _cairo_traps_compositor_glyphs"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103037#c15">Comment # 15</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Segmentation fault in _cairo_traps_compositor_glyphs"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103037">bug 103037</a>
from <span class="vcard"><a class="email" href="mailto:spitzak@gmail.com" title="Bill Spitzak <spitzak@gmail.com>"> <span class="fn">Bill Spitzak</span></a>
</span></b>
<pre>+ assert (0 && "incorrect use of _cairo_atomic_init_once API (once !=
CAIRO_ATOMIC_ONCE_INITIALIZING)");
I think it would be better for the error message to read "use of
_cairo_atomic_init_once_leave without _cairo_atomic_init_once_enter".
Unless you really see another way for that assert to be triggered.
Also it is an annoying fact of life that on the x86 the fastest way to read an
atomic variable "works" in a very useful way:
Thread 1:
// x is a large structure, y is a lock-free atomic
x = foo;
atomic_set(y, 1);
// never set y again
Thread 2:
// do not read x here
while (y != 1) { // non-atomic read!
// code that does other atomic operations
}
assert( x == foo ); // this works
Vast amounts of software assumes this works. The trick is that there is no
synchronization, but an assumption that the only way for y==1 to be true is for
a sync to have happened since the atomic_set.
It does not seem like any version of the atomic operations produce the same
instructions as the non-atomic read in GCC. All of them produce a "sync"
(except "relaxed" but that clearly states the assert could fail).
I am certainly not a mt expert, but I have seen people complain about this with
the atomic operations plenty of times to see if anybody can answer this with
one of these answers:
1. Everybody is wrong and the above code can fail on Intel-style processors.
2. The way you get the above in a form that can be ported to other platforms is
to do "<code>".
3. The overhead of the sync is zero (not impossible, the compiler could
optimize it out by seeing that the test is in a loop).
4. Answer 2 or 3 except it is not true because GCC has a bug.
Probably not a big deal for this bit of Cairo, but this can add up, and there
seem to be some experts here as well as people asking this question, so maybe
somebody here can answer it.
, and also the docs claim that you should use "release" when setting the
variable and mixing modes will screw things up, and this code does not want to
do that as it is reusing code that makes more strict assumptions about the
setting of y.
, the missing assumption is that if the sync has not completed then you will
not see a value of y==1.
. I am guessing that "aquire" is supposed to do this but it is not doing it.
And it does not seem to correspond exactly to any atomic model. Maybe "aquire"
except the aquire semantics only apply if a particular value is read. This code
does rely on the fact that x is only referred to in the if statement to prevent
any out-of-order read of x before y is read.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>