|
|
i |
Re: [PATCHv5 2/2] memory barrier: adding smp_mb__after_lock | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
Herbert Xu a écrit : > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx> 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 ? Also, how many arches are able to have a true __read_lock() (or __spin_lock() if that matters), without acquire semantic ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[Kernel List] [Site Home] [Ethernet Bridging] [Git] [IETF Annouce] [Linux Assembly] [VLAN] [Networking] [Security] [Bugtraq] [Rubini] [Photo] [Singles Social Networking] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Virtualization] [Linux Security] [Linux IDE] [Linux RAID] [Linux SCSI] [Linux Wireless] [DDR & Rambus] [Free Dating] [Linux Resources] [Wireless Reading Device]
![]() |
![]() |