Date: Fri, 27 Dec 2019 11:50:02 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Ronald Klop <ronald-lists@klop.ws>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Mateusz Guzik <mjg@freebsd.org> Subject: Re: svn commit: r356120 - head/sys/security/mac Message-ID: <053d786b-b3ed-53e3-e863-45801dbcd933@selasky.org> In-Reply-To: <op.0dgfqujxkndu52@sjakie> References: <201912271123.xBRBNWow013539@repo.freebsd.org> <op.0dgfqujxkndu52@sjakie>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-12-27 12:33, Ronald Klop wrote:
> Wow, this looks like a winner.
>
> Ronald.
Is this a spin-off from epoch methodology?
It is possible to use epoch as a part of read mostly locking too.
The basic idea here is to have a variable/refcount which when set,
fallback to a regular mutex during read-locking. This is all
synchronized under epoch.
Pseudo code:
read_lock() {
epoch_enter();
do_lock = writers != 0;
if (do_lock)
mtx_lock();
}
read_unlock() {
if (do_lock)
mtx_unlock();
epoch_exit();
}
write_lock() {
writers++;
epoch_wait();
mtx_lock();
}
write_unlock() {
mtx_unlock();
writers--;
epoch_wait();
}
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?053d786b-b3ed-53e3-e863-45801dbcd933>