Messages in this thread | | | Date | Fri, 3 Jul 2009 10:06:22 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCHv5 2/2] memory barrier: adding smp_mb__after_lock |
| |
On Fri, Jul 03, 2009 at 11:47:00AM -0400, Mathieu Desnoyers wrote: > * Eric Dumazet (eric.dumazet@gmail.com) wrote: > > Herbert Xu a écrit : > > > Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote: > > >> Why don't we create a read_lock without acquire semantic instead (e.g. > > >> read_lock_nomb(), or something with a better name like __read_lock()) ? > > >> On architectures where memory barriers are needed to provide the acquire > > >> semantic, it would be faster to do : > > >> > > >> __read_lock(); > > >> smp_mb(); > > >> > > >> than : > > >> > > >> read_lock(); <- e.g. lwsync + isync or something like that > > >> smp_mb(); <- full sync. > > > > > > Hmm, why do we even care when read_lock should just die? > > > > > > Cheers, > > > > +1 :) > > > > Do you mean using a spinlock instead or what ? > > > > I think he meant RCU. > > > Also, how many arches are able to have a true __read_lock() > > (or __spin_lock() if that matters), without acquire semantic ? > > At least PowerPC, MIPS, recent ARM, alpha.
Are you guys sure you are in agreement about what you all mean by "acquire semantics"?
Clearly, any correct __read_lock() implementation must enforce ordering with respect to the most recent __write_unlock(), but this does not necesarily imply all possible definitions of "acquire semantics".
Thanx, Paul -- 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/
| |