Messages in this thread | | | Date | Thu, 21 Oct 2004 12:49:30 -0400 | From | john cooper <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 |
| |
Eugeny S. Mints wrote:
> john cooper wrote: > >> A task holding several mutexes shouldn't be an issue. >> Though per task an ownership list needs to be maintained >> in descending priority order such that the effective PI >> can be resolved from all task owned mutexes. > > > Seems it is too coplex model at least for the first step. The one of > possible trade-offs coming on mind is to trace the number of resources > (mutexes) held by a process and to restore original priority only when > resource count reaches 0. This is one of the sollutions accepted by > RTOS guys.
It would seem a mutex ownership list still needs to be maintained. Doing so in unordered priority will give a small fixed insertion time, but will require an exhaustive search in order to calculate maximum priority. Doing so in priority order will require an average of #mutex_owned / 2 for the insertion, and gives a fixed time for maximum priority calculation. The latter appears to offer a performance benefit to the degree the incoming priorities are random.
> The other concern with PI is that most likely PI should be prohibited > for utilization with locks which are used in the way similar to > "waiting completition" - i.e. if PI is employed on a mutex it is > prohibited to release it if a process is not the owner of the mutex.
Yes, that type of usage breaks the notion of ownership. It would be a error for a task to attempt relinquishing a mutex which it had not acquired and was holding at the time of unlock.
>> http://developer.osdl.org/dev/robustmutexes > > > It is definitly non-trivial work to adapt this approach - there are a > lot of issues.
I should have qualified that reference. Those folks are addressing more than PI mutexes. Indeed their goal is support of fast user mutexes which offer detection of mutex owners gone astray (exited, killed, etc..). It is the kernel component of the work to which I was referring.
-john
-- john.cooper@timesys.com
- 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/
| |