Re: FUSYN and RT

[Esben Nielsen <simlo@phys.au.dk>]

On 12 Apr 2005, Daniel Walker wrote:

> 
> I just wanted to discuss the problem a little more. From all the
> conversations that I've had it seem that everyone is worried about
> having PI in Fusyn, and PI in the RT mutex. 
> 
> It seems like these two locks are going to interact on a very limited
> basis. Fusyn will be the user space mutex, and the RT mutex is only in
> the kernel. You can't lock an RT mutex and hold it, then lock a Fusyn
> mutex (anyone disagree?). That is assuming Fusyn stays in user space.
> 
> The RT mutex will never lower a tasks priority lower than the priority
> given to it by locking a Fusyn lock.

I have not seen the Fusyn code. Where is the before-any-lock priority
stored? Ingo's code sets the prio back to what is given by static_prio.
So, if Fusyn sets static_prio it will work as you say. It it will then be
up to Fusyn to restore static_prio to what it was before the first Fusyn
lock.

> 
> At least, both mutexes will need to use the same API to raise and lower
> priorities.

You basicly need 3 priorities:
1) Actual: task->prio
2) Base prio with no RT locks taken: task->static_prio
3) Base prio with no Fusyn locks taken: task->??

So no, you will not need the same API, at all :-) Fusyn manipulates
task->static_prio and only task->prio when no RT lock is taken. When the
first RT-lock is taken/released it manipulates task->prio only. A release
of a Fusyn will manipulate task->static_prio as well as task->prio.

> 
> The next question is deadlocks. Because one mutex is only in the kernel,
> and the other is only in user space, it seems that deadlocks will only
> occur when a process holds locks that are all the same type.

Yes.
All these things assumes a clear lock nesting: Fusyns are on the outer
level, RT locks on the inner level. What happens if there is a bug in RT
locking code will be unclear. On the other hand errors in Fusyn locking
(user space) should not give problems in the kernel.

> 
> 
> Daniel
> 

I think that it might be a fast track to get things done to have a double
PI-locking system, one for the kernel and one for userspace. But I think
it is is bad maintainance to have to maintain two seperate systems. The
best way ought to be to try to only have one PI system. The kernel is big
and confusing enough as it is!

Esben

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