Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

["Eugeny S. Mints" <emints@ru.mvista.com>]

john cooper wrote:
> Esben Nielsen wrote:
> 
>> On Thu, 21 Oct 2004, john cooper wrote:
>>
>>> Mutexes layered on existing semaphores seems convenient
>>> at the moment. However a more native mutex mechanism
>>> which tracks ownership would provide a basis for PI as
>>> well as further instrumentation. This may not be an
>>> issue at the present but I don't think it is too far
>>> off.
>>>
>>> -john
>>>
>>>
>>
>> Actually you need to have another kind of semaphore based on a new 
>> kind of
>> wait-queue: Priority based. I.e. the task with the highest priority get
>> woken up first. Then on top of that you build your mutex.
>>
> That more/less falls out of the PI mechanism. Though it
> appears conserving per-mutex data footprint and O(1)
> behavior are going to be at odds.
> 
>> I was planning to start to look at it and try to see if I could get
>> anything to work, but I must admit I haven't got much further than
>> just getting Igno's -U8.1 up running.
>>
> I myself wonder whether Ingo is 1 or N people.
> 
>> To get a mutex with priority inheritance add an element pointing to the
>> current owner and a field where you store the owners original priority
>> which it has to be set back to when it relases the mutex (I am not sure
>> how this will work out if someone holds several mutexes!)
>>
> 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.

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.

> 
> Also a multiple ownership model is needed for the case of
> shared-reader locks. This results in a list of owners
> where the list element can maintain per-mutex task ownership
> as well as per-task mutex ownerships.
> It is tempting to re-implement the wheel here but existing
> works are well on their way:
> 
> http://developer.osdl.org/dev/robustmutexes

It is definitly non-trivial work to adapt this approach - there are a 
lot of issues.

				Eugeny
> -john
>