On Fri, 28 Jan 2005, Ingo Molnar wrote: > > * Esben Nielsen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
