[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pserialized reader/writer locks
Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> Date: Sat, 26 Jul 2014 16:48:27 +0100
> From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
> I would expect a better problem statement even if it is a brain dump
> (one sentence would have been enough). Are you trying to solve sleepable
> reader problem? In such case, messing up pserialize(9) with somewhat
> read-write lock semantics in ad-hoc way is a wrong approach. If you are
> building a read-optimised *lock*, then it should be designed and
> implemented as such mechanism rather than built as an ad-hoc wrapper.
> The object is scalable nestable transactions: entering and exiting a
> transaction should not usually incur interprocessor synchronization,
> and threads in transactions may sleep.
Yes, that is what read-optimised locks and/or SRCU are for.
> Basically, there are two approaches:
> a) Implement read-optimised / read-mostly lock. Years ago ad@ wrote an
> implementation of rdlock(9). It was not published, but he added a BSD
> license so I guess it is okay to post here:
> That makes a single reader cheap; doesn't make multiple readers
> Alternatively, there is FreeBSD's rmlock(9):
> That doesn't allow sleeping during a transaction.
Okay, indeed. If they implemented read-mostly lock, they should have added
sleepable reader support (since it already has all the means for that).
> b) Implement grace-period based synchronisation mechanism which allows
> readers to sleep, such as SRCU. There are some dangers here:
> However, it can provide less expensive writer side and more granular
> garbage collection of objects. I think it is worth to consider this
> Less expensive writer side is not the point here.
The point is that it provides what you want, plus more.
Main Index |
Thread Index |