Date: Sat, 20 Aug 2005 18:39:49 -0400 From: Stephan Uphoff <ups@tree.com> To: Luigi Rizzo <rizzo@icir.org> Cc: arch@freebsd.org, Max Laier <max@love2party.net>, net@freebsd.org Subject: Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c Message-ID: <1124577589.1360.73337.camel@palm> In-Reply-To: <20050818073124.A87225@xorpc.icir.org> References: <20050816170519.A74422@xorpc.icir.org> <200508170435.34688.max@love2party.net> <20050817170248.A70991@xorpc.icir.org> <200508180332.34895.max@love2party.net> <20050818005739.A83776@xorpc.icir.org> <1124374713.1360.64660.camel@palm> <20050818073124.A87225@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2005-08-18 at 10:31, Luigi Rizzo wrote:
> On Thu, Aug 18, 2005 at 10:18:33AM -0400, Stephan Uphoff wrote:
> > On Thu, 2005-08-18 at 03:57, Luigi Rizzo wrote:
> ...
> > > In fact i don't understand why you consider spinning and sleeping
> > > on a mutex two different things.
> >
> > The major difference between sleeping (cv_wait,msleep,..) and blocking
> > on a mutex is priority inheritance.
> > If you need to be able to use (non-spin) mutexes while holding a
> > [R|W]LOCK and use a [R|W]LOCK while holding a (non-spin) mutex then you
> > need to implement priority inheritance for [R|W]LOCKs.
>
> is that required (in FreeBSD, i mean) for algorithmic
> correctness or just for performance ?
Hi Luigi,
It is theoretically required since otherwise low priority user threads
(programs) could block system (interrupt) threads indefinitely long.
Example:
Extreme low priority (nice?) thread A holds read/write
lock RW as reader
Thread B is holding mutex M tries to acquire read/write lock
RW as writer and sleeps.
Thread C with better priority than A runs and enters a
busy loop (in user space).
Interrupt thread preempts C and tries to acquire Mutex M.
Interrupt priority is propagated to B BUT NOT TO A.
Interrupt thread blocks on Mutex M.
Thread C resumes and will block thread I forever if it
can keep a better priority than thread A.
In practice you would probably just see bad latency every now and then
and may never encounter a hang.
Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1124577589.1360.73337.camel>