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

[Eugeny S. Mints]

john cooper wrote:
> 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.

Yes, definilty, I 100% agree with you - I have _not_ disputed the 
priority list approach at all.

> > 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.

exactly

> > > 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.

Ok, I've also talked about kernel component not user space one. User 
space approach with robustness, fast uncontented obtaining, etc looks 
very attractive but both kernel and user space parts have their issues -
though I took a glance to the project about 2 months ago.

			Eugeny


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/