On Thu, 2007-07-19 at 19:57 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > Ok, the rpilock is local, the nesting level is bearable, let's focus on > > putting this thingy straight. >
Sorry, I missed this one, which in fact explains that you were referring to Xenomai PI and not PREEMPT_RT PI (yeah, I thought for a while that you were nuts enough to ask me to model RPI after RT-PI... so I must be nuts myself) > Well, redesigning things may not necessarily improve the situation, but > reducing the amount of special RPI code might be worth a thought: > > What is so special about RPI compared to standard prio inheritance? Basically, boost propagation and priority backtracking as I previously answered in the wrong context. This said, I still think that PI (the Xenomai one) complexity is much higher than RPI in its current form. > What > about [wild idea ahead!] modelling RPI as a virtual mutex that is > permanently held by the ROOT thread and which relaxed threads try to > acquire? They would never get it, rather drop the request (and thus the > inheritance) once they are to be hardened again or Linux starts to > schedule around. > > *If* that is possible, we would > A) reuse existing code heavily, > B) lack any argument for separate locking, > C) make things far easier to understand and review. > > Sounds too beautiful to work, I'm afraid... > It would be more elegant than RPI currently is, not question. This is the way message passing works in the native API, in order to implement the inheritance by the server of the client priority, for instance. The main problem with PI, is that all starts from xnsynch_sleep_on. Since we could not use this interface to activate PI, we would have to craft another one. Additionally, some Linux activities may change the RPI state (e.g. sched_setscheduler()), so we would have to create a parallel path to fix this state without resorting to the normal PI mechanism aimed at being used over a blockable context, Xenomai-wise. A lot of changes for the purpose of solely recycling the basics of a PI implementation. > Jan > -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
