Messages in this thread | | | Date | Sun, 30 Jan 2005 23:03:12 +0100 (MET) | From | Esben Nielsen <> | Subject | Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15) |
| |
On Fri, 28 Jan 2005, Ingo Molnar wrote:
> > * 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. > I agree that RCU ought to do the trick in a lot of cases. Unfortunately, people haven't used RCU in a lot of code but an rwlock. I also like the idea of rwlocks: Many readers or just one writer. I don't see the need to take that away from people. Here is an examble which even on a UP will give problems without it: You have a shared datastructure, rarely updated with many readers. A low priority task is reading it. That is preempted a high priority task which finds out it can't read it -> priority inheritance, task switch. The low priority task finishes the job -> priority set back, task switch. If it was done with a rwlock two task switchs would have been saved.
> > 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. > Yes it does. But one could make a compromise: The up_write() should _not_ be deterministic. In that case it would be very simple to implement. up_read() could still be deterministic as it would only involve boosting one writer in the rare case such exists. That kind of locking would be very usefull in many real-time systems. Ofcourse, RCU can do the job as well, but it puts a lot of contrains on the code.
However, as Linux is a general OS there is no way to know wether a specific lock needs to be determnistic wrt. writing or not as the actual application is not known at the time the lock type is specified.
> Ingo >
Esben
- 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/
| |