A realtime preemption overview

Posted Aug 19, 2005 21:43 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link]

One could indeed upgrade a single reader at a time, and on a single-CPU system this might make sense (and rumor has it that some RTOSes actually do take this approach). But on (say) a 4-CPU system, you could potentially be handling four readers at a time, and so upgrading a single reader at a time would result in delaying the high-priority waiting writer four times longer than necessary. This added scheduling delay will be unacceptable for some applications. And commodity multi-CPU systems (hyperthreading, dual cores) are becoming readily available at reasonable cost. A single-chip 4-CPU ARM system was demoed recently, so even the deep embedded CPUs are starting to take this approach.

OK, so you could upgrade N readers at a time, where N is the number of CPUs. But suppose we are doing priority inheritance for semaphores, and one of the readers blocks. Then we again have an idle CPU that could be getting readers out of the way of the high-priority waiting writer, again, needlessly degrading the waiting writer's scheduling latency.

And this latter issue causes problems even on a single-CPU system. :-(

Therefore, the current approach is to allow only one reader task at a time to hold a reader-writer lock or semaphore.