10 messages in org.freebsd.freebsd-netduplicate read/write locks in net/pf...| From | Sent On | Attachments |
|---|---|---|
| Luigi Rizzo | Aug 17, 2005 12:05 am | |
| Max Laier | Aug 17, 2005 2:35 am | |
| Julian Elischer | Aug 17, 2005 3:20 am | |
| Luigi Rizzo | Aug 18, 2005 12:02 am | |
| Max Laier | Aug 18, 2005 1:32 am | |
| Luigi Rizzo | Aug 18, 2005 7:57 am | |
| Luigi Rizzo | Aug 18, 2005 2:31 pm | |
| John Baldwin | Aug 18, 2005 4:28 pm | |
| Stephan Uphoff | Aug 20, 2005 10:39 pm | |
| Stephan Uphoff | Aug 20, 2005 11:02 pm |
| Subject: | duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c | |
|---|---|---|
| From: | Stephan Uphoff (up...@tree.com) | |
| Date: | Aug 20, 2005 10:39:38 pm | |
| List: | org.freebsd.freebsd-net | |
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