Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
From: Luigi Rizzo (rizzo_at_icir.org)
Date: 08/18/05
- Previous message: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- In reply to: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- Next in thread: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- Reply: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 18 Aug 2005 07:31:24 -0700 To: Stephan Uphoff <ups@tree.com>
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 ?
cheers
luigi
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- In reply to: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- Next in thread: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- Reply: Stephan Uphoff: "Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
... >> In fact i don't understand why you consider spinning and sleeping ...
> The major difference between sleeping and blocking ... > on a mutex
is priority inheritance. ... (freebsd-net) - Re: msleep() on recursivly locked mutexes
... Further the idea that holding a mutex "except for when we sleep" is a generally
... first a blocking lock and later a sleeping lock, ... it is not always possible
to drop the blocking lock ... (freebsd-hackers) - Re: "sleeping without a mutex" panic with FixitCD from todays SNAP
... SL>> # make installkernel KERNCONF=GENERIC ... SL>> <panic: sleeping
without a mutex ... SL> chance that you could do that? ... (freebsd-current) - Re: propagate_priority KASSERT
... > We're currently tripping accross the following KASSERT in ... Priority
inheritance is needed to avoid blocking interrupt threads for a ... A thread sleeping
while holding a mutex would break priority ... (freebsd-stable) - Re: Lockfree or not to lockfree thats the question !
... I simply presented a list of lock-free algorithms downsides. ... sure people
understood the downside of lock-free algorithms. ... Explain in detail how spinning
on an adaptive mutex's internal state _fundamentally_ differs from spinning on a CAS failure wrt lock-free
algorithms in general? ... A little spin on the mutex is fine, as it can increase performance
somewhat by turning things into a "temporary" spinlock-and-backoff semantics before the "ultimate" slow-path
is hit, thus delegating to the kernel waitset that happens to be assigned to said mutex synchronization
logic... ... (comp.programming.threads)