<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Once upon a time, on 02/08/2013 04:02
      PM to be precise, Jonas Maebe said:<br>
    </div>
    <blockquote
      cite="mid:904AF467-35D5-41FA-BB8B-6BEC95261697@elis.ugent.be"
      type="cite"><br>
      <div>
        <div>On 07 Feb 2013, at 16:52, Ewald wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite"><span class="Apple-style-span"
            style="border-collapse: separate; color: rgb(0, 0, 0);
            font-family: Monaco; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: 2; text-align: -webkit-auto;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: 2; word-spacing: 0px;
            -webkit-border-horizontal-spacing: 0px;
            -webkit-border-vertical-spacing: 0px;
            -webkit-text-decorations-in-effect: none;
            -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
            0px; font-size: medium; "><span class="Apple-style-span"
              style="font-family: monospace; ">Altough I still<br>
              don't see how you can make these calls atomic then
              (without the<br>
              barrier)?</span></span></blockquote>
      </div>
      <br>
      <div>On x86, it is impossible to perform an atomic access without
        a (partial) memory barrier that affects all memory (due to the
        behaviour of the "lock" prefix). On other architectures, the
        instructions for atomic accesses may only lock the cacheline or
        memory page containing the value to be atomically modified.
        I.e., they are only a barrier for that cacheline/page, not for
        the entire memory.</div>
      <div><br>
      </div>
      <div>Or not even that: older SPARC architectures only had a
        test-and-set instruction, which only supported switching between
        0 and 1. So basically you had to use a single global lock
        variable, which you locked using this instruction, then you
        modified the "atomic value" using regular instructions, and then
        unlocked the global lock again. So any atomic update conflicted
        with any other atomic update, regardless of where the values
        were located, and there was no memory barrier whatsoever (except
        for this one lock variable). And it only worked if all code in
        the entire program made use of the same global lock variable.
        It's similar for older ARM CPUs.</div>
    </blockquote>
    Now I see, thanks for the explanation!<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Ewald
</pre>
  </body>
</html>