On 31 October 2012 23:30, Peter Fordham <span dir="ltr">&lt;<a href="mailto:peter.fordham@gmail.com" target="_blank">peter.fordham@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK so if I understand you correctly your saying that the memory<br>
barriers aren&#39;t fundamental to the correct operation of this spinlock<br>
itself but are required to make all the memory access started inside<br>
the critical section actually complete inside the critical section,<br>
right?<br></blockquote><div><br></div><div>Partially.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess what I&#39;m saying is that isn&#39;t it up to the calling code to<br>
decide exactly how this should be done rather than the locking code.<br>
For example, if I&#39;m just using a spinlock in the place of a mutex in a<br>
time critical section of where I want to avoid a call into the<br>
scheduler and I&#39;m not really poking registers in a memory mapped<br>
device, just updating some shared data structure in normal cache-able<br>
memory, it seems inappropriate to use DMBs. I see examples of this in<br>
the ext4 code.<br>
<br>
In real driver code where we do access registers, shouldn&#39;t the driver<br>
be responsible for calling smp_mb where appropriate?</blockquote><div><br></div><div>Its not about registers at all. Suppose you have following code sequence:</div><div><br></div><div>global variable x = 0;</div><div><br>
</div><div>fn-1()</div><div>{</div><div>  while (1) {</div><div>     spin_lock()</div><div>      if (x == 1) {<br>           spin_unlock();</div><div>            return;</div><div>      }</div><div>     spin_unlock();</div>
<div>   }</div><div>}</div><div><br></div><div>And in an interrupt handler</div><div><br></div><div>handler()</div><div>{</div><div>spin_lock();</div><div>x=1;</div><div><br></div><div>if (some-other-event)</div><div>  x = 0;</div>
<div>spin_unlock();</div><div>}</div><div><br></div><div>Now, suppose this some-other-event is returning true for us. Then the</div><div>expected behavior of this code should be, the first function is running</div><div>an infinite loop.</div>
<div><br></div><div>But for ARMv6 and above normal memory is weakly ordered. i.e. compiler</div><div>and processor are free to move instructions doing reads writes to memory</div><div>before and after other instructions. Also, they can break one memory transaction</div>
<div>into two and join 2 into one... etc..</div><div><br></div><div>Now who will guarantee that, x is always read after taking the lock in function 1?</div><div>Because if x moves before the instruction doing the increment on spin_lock variable,</div>
<div>then value of x may be read when it is made 1 by the handler and so before the</div><div>lock is released by the handler.</div><div><br></div><div>So, it is responsibility of  lock,unlock to make sure that instructions executed within</div>
<div>lock/unlock must stay within these two and don&#39;t jump out. This is not guaranteed</div><div>with ARMv6 and above.</div><div><br></div><div>STREX and LDREX are for atomic load and store on SMP systems</div><div><br>
</div><div>Hope you understood what i am pointing at??</div><div><br></div><div>--</div><div>viresh</div></div>