* Sasha Levin <[email protected]> wrote:
> On Fri, 2011-05-27 at 12:36 +0200, Ingo Molnar wrote:
> > * Sasha Levin <[email protected]> wrote:
> >
> > > I see that in liburcu there is an implementation of a rcu linked
> > > list but no implementation of a rb-tree.
> >
> > Another approach would be, until the RCU interactions are sorted out,
> > to implement a 'big reader lock' thing that is completely lockless on
> > the read side (!).
> >
> > It works well if the write side is expensive, but very rare: which is
> > certainly the case for these ioport registration data structures used
> > in the mmio event demux fast path!
> >
> > The write_lock() side signals all worker threads to finish whatever
> > they are doing now and to wait for the write_unlock(). Then the
> > modification can be done and the worker threads can be resumed.
> >
> > This can be updated to RCU later on without much trouble.
> >
> > The advantage is that this could be implemented with the existing
> > thread-pool primitives straight away i think, we'd need five
> > primitives:
> >
> > bread_lock();
> > bread_unlock();
> > bwrite_lock();
> > bwrite_lock();
> >
> > brlock_init();
> >
> > and a data type:
> >
> > struct brlock;
> >
> > bread_lock()/bread_unlock() is basically just a compiler barrier.
> > bwrite_lock() stops all (other) worker threads.
> > bwrite_unlock() resumes them.
> >
> > That's all - should be 50 lines of code, unless i'm missing something
> > :-)
> >
> > Thanks,
> >
> > Ingo
>
> Isn't there something similar to this in the kernel?
Yeah, there's include/linux/lglock.h.
> I prefer not implementing a new lock type at the moment mostly because
> we're not tackling a bug or an immediate problem, we don't really need
> locking at the moment (we add all devices at init and don't support
> hotplug yet). So I'd rather not write code just to solve it faster but
> have it thrown away later.
We don't have to throw it away: RCU is rather complex to pull off
here, and in many cases, where writes are very rare, brlocks are the
best solution even with RCU present.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
