The FAQ concludes with "Ask us." I fully understand that any priority or exclusion mechanism can bite if used incorrectly. An knife can kill, that doesn't make it useless or always bad. I completely agree with "operations on shared resources are simple and fast".
However, without some form of priority inheritence, mutexes can't assure fast access and release. It seems that the only option available is FIFOs. In the case of a service like a device driver, this means that the device driver must have its own thread who's priority is known to be the same or higher than its highest priority "client". This often seems unsatisfactory. Why is priority inheritance not a valid tool? Obviously, you would need to keep your use of the mutex "simple and fast" and doing stupid things like grabbing a mutex and sleeping for a random amount of time is just stupid. I'd be happy to have mutexes have priorities associated with them and the client must delcare what the priority should be when claiming it. If the client either declares the wrong value or the priority of the mutex is lower then the thread claiming it an assert is triggered. This at least checks on you being stupid and not knowing how fast you need to be when using the mutex. Other than FIFO's, what mechanisms can be used without any form of priority management? I've asked this question several times and never seen a response. I have seen Victor tear people apart for suggesting priority inheritance on several lists but I have yet to see a real explaination of the alluded to alternatives. Pointers to papers, books, etc. are very reasonable replies to my question. Thanks! Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Military Systems Division [EMAIL PROTECTED] Robots for the Real World 603-532-6900 ext 206 http://www.irobot.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
