![]() | |||||||||||||
Messages in this thread |
On 11/24, Alan Stern wrote: > > On Fri, 24 Nov 2006, Oleg Nesterov wrote: > > > Ok, synchronize_xxx() passed 1 hour rcutorture test on dual P-III. > > > > It behaves the same as srcu but optimized for writers. The fast path > > for synchronize_xxx() is mutex_lock() + atomic_read() + mutex_unlock(). > > The slow path is __wait_event(), no polling. However, the reader does > > atomic inc/dec on lock/unlock, and the counters are not per-cpu. > > > > Jens, is it ok for you? Alan, Paul, what is your opinion? > > Given that you aren't using per-cpu data, why not just rely on a spinlock? I thought about this too, and we can re-use sp->wq.lock, > Then everything will be simple and easy to verify, xxx_read_lock() will be simpler, but not too much. synchronize_xxx() needs some complication. > with no need to worry > about atomic instructions or memory barriers. spin_lock() + spin_unlock() doesn't imply mb(), it allows subsequent loads to move into the the critical region. I personally prefer this way, but may be you are right. Oleg. - 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-11-24 22:15 [from the cache] ©2003-2008 | |||||||||||||