Messages in this thread | | | Date | Fri, 28 Jan 2005 08:38:56 +0100 | From | Ingo Molnar <> | Subject | Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15) |
| |
* Esben Nielsen <simlo@phys.au.dk> wrote:
> I noticed that you changed rw-locks to behave quite diferently under > real-time preemption: They basicly works like normal locks now. I.e. > there can only be one reader task within each region. This can can > however lock the region recursively. [...]
correct.
> [...] I wanted to start looking at fixing that because it ought to > hurt scalability quite a bit - and even on UP create a few unneeded > task-switchs. [...]
no, it's not a big scalability problem. rwlocks are really a mistake - if you want scalability and spinlocks/semaphores are not enough then one should either use per-CPU locks or lockless structures. rwlocks/rwsems will very unlikely help much.
> However, the more I think about it the bigger the problem:
yes, that complexity to get it perform in a deterministic manner is why i introduced this (major!) simplification of locking. It turns out that most of the time the actual use of rwlocks matches this simplified 'owner-recursive exclusive lock' semantics, so we are lucky.
look at what kind of worst-case scenarios there may already be with multiple spinlocks (blocker.c). With rwlocks that just gets insane.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |