[patch 00/21] mutex subsystem, -V14

[Joel Schopp]

> ISYNC_ON_SMP flushes all speculative reads currently in the queue - and 
> is hence a smp_rmb_backwards() primitive [per my previous mail] - but 
> does not affect writes - correct?
> 
> if that's the case, what prevents a store from within the critical 
> section going up to right after the EIEIO_ON_SMP, but before the 
> atomic-dec instructions? Does any of those instructions imply some 
> barrier perhaps? Are writes always ordered perhaps (like on x86 CPUs), 
> and hence the store before the bne is an effective write-barrier?

It really makes more sense after reading PowerPC Book II, which you can find at 
this link, it was written by people who explain this for a living: 
http://www-128.ibm.com/developerworks/eserver/articles/archguide.html

While isync technically doesn't order stores it does order instructions.  The 
previous bne- must complete, that bne- is dependent on the previous stwcx being 
complete.  So no stores are slipping up.  To get a better explanation you will 
have to read the document yourself.

Here is a first pass at a powerpc file for the fast paths just as an FYI/RFC. 
It is completely untested, but compiles.

Signed-off-by: Joel Schopp <jschopp at austin.ibm.com>



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: powerpcmutex.patch
Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060105/e2d51f53/attachment.txt