![]() | |||||||||||||
Messages in this thread |
Nick Piggin wrote: > OK, you believe that the mutex *must* be granted to a blocking thread > at the time of the unlock. I don't think this is unreasonable from the > wording (because it does not seem to be completely unambiguous english), > however think about this - > > A realtime system with tasks A and B, A has an RT scheduling priority of > 1, and B is 2. A and B are both runnable, so A is running. A takes a > mutex > then sleeps, B runs and ends up blocked on the mutex. A wakes up and at > some point it drops the mutex and then tries to take it again. > > What happens? > > I haven't programmed realtime systems of any complexity, but I'd think it > would be undesirable if A were to block and allow B to run at this point. But why does A take the mutex in the first place? Presumably because it is about to execute a critical section. And also presumably, A will not release the mutex until it no longer has anything critical to do; certainly it could hold it longer if it needed to. If A still needed the mutex, why release it and reacquire it, why not just hold onto it? The fact that it is being released is significant. > Now this has nothing to do with PI or SCHED_OTHER, so behaviour is > exactly > determined by our respective interpretations of what it means for "the > scheduling policy to decide which task gets the mutex". > > What have I proven? Nothing ;) but perhaps my question could be answered > by someone who knows a lot more about RT systems than I. In the last RT work I did 12-13 years ago, there was only one high priority producer task and it was never allowed to block. The consumers just kept up as best they could (multi-proc machine of course). I've seldom seen a need for many priority levels. Probably not much you can generalzie from this though. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-01-26 22:36 [from the cache] ©2003-2008 | |||||||||||||