<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#c20">Comment # 20</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:ajohnson@redneon.com" title="Adrian Johnson <ajohnson@redneon.com>"> <span class="fn">Adrian Johnson</span></a>
</span></b>
        <pre>(In reply to Bill Spitzak from <a href="show_bug.cgi?id=103037#c15">comment #15</a>)
<span class="quote">>   Thread 2:
>   // do not read x here
>   while (y != 1) { // non-atomic read!
>     // code that does other atomic operations
>   }
>   assert( x == foo ); // this works</span >

That is relying on undefined behavior. Future versions of the compiler may
decided to optimize away second and subsequent reads. 

<span class="quote">> Vast amounts of software assumes this works.</span >

As we saw with the gcc integer overflow optimizations many years ago, the
compiler developers will be unsympathetic to this argument and point you to the
spec.

I had a look around for performance figures on atomic reads and came across
this:

<a href="https://htor.inf.ethz.ch/publications/img/atomic-bench.pdf">https://htor.inf.ethz.ch/publications/img/atomic-bench.pdf</a>

I don't think the cost of an atomic read is worth trying to optimize. In any
case, it is the job of the compiler to implement the read in the fastest way
possible.</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>