tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pserialized reader/writer locks

Taylor R Campbell <> wrote:
>    Date: Sat, 26 Jul 2014 16:48:27 +0100
>    From: Mindaugas Rasiukevicius <>
>    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
> scalable.


>    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
> way.
> Less expensive writer side is not the point here.

The point is that it provides what you want, plus more.


Home | Main Index | Thread Index | Old Index