lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/21] mutex subsystem, -V14

* Joel Schopp <jschopp@austin.ibm.com> wrote:

> The bne- and isync together form a sufficient import barrier. See
> PowerPC Book2 Appendix B.2.1.1

ok. Please correct me if i'm wrong: the question is, could we on ppc64
use atomic_dec_return() for mutex_lock(), and atomic_inc_return() for
mutex_unlock().

atomic_dec_return() does:

EIEIO_ON_SMP
"1: lwarx %0,0,%1 # atomic_dec_return\n\
addic %0,%0,-1\n"
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1\n\
bne- 1b"
ISYNC_ON_SMP

the EIEIO_ON_SMP is in essence smp_wmb(), correct? (it's a bit stronger
because it also orders IO-space writes, but it doesnt impose any
restrictions on reads)

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?

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-05 23:24    [from the cache]
©2003-2011 Jasper Spaans