Carsten Emde wrote:
So why are we not allowed to call this "hard real-time"?
:-) I guess the disconnect is that even an RTOS can't guarantee timing when the user didn't analysed his application software with due diligence before going into production. For example, someone can very well do something like "for(;;);" at fifo priority 99, locking out all other threads completely. The RTOS might think this is what the user likes to do - means: an RTOS doesn't prevent a user to do silly things! In this respect, it is even more dangerous if i.e. multimedia application make use of real time priorties, because it can easily lookup the whole system whereas "nice" priorities only reduce system responsivness in case something went wrong. Even if the developer carefully reviews what the application is doing, then there is still the risk that he has overlooked something. This is the reason why RTOSes like OSEK have a "timing protection" that checks if a certain thread doesn't exceed a given amount of allowed time per system cycle. Not truly the best solution, either, but at least a means of detecting that something went wrong ... Concerning locking: the amount of time a low priority thread holds a lock and in turn prevents a high priority thread from acquiring it is a pure application problem (means, something the developer has to take care about). However, -rt implements the priority inheritance protocol to soften that issue. BTW.: Avoiding locks is a good real time programming practice, *g* (However this is not always achivable). regards Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
