RE: FUSYN and RT

["Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>]

>From: Esben Nielsen [mailto:simlo@phys.au.dk]
>On 12 Apr 2005, Daniel Walker wrote:
>
>>
>>
>> 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.

Yes you do. You took care of the simple case. Things get funnier
when you own more than one PI lock, or you need to promote a
task that is blocked on other PI locks whose owners are blocked
on PI locks (transitivity), or when you mix PI and PP (priority
protection/ priority ceiling).

In that case not having a sim{pl,g}e API for doing it is nuts.

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

Wrong. Fusyns are kernel locks that are exposed to user space (much as
a file descriptor is a kernel object exposed to user space through
a system call). Of course if the user does something mean with them
they will cause an error, but should not have undesired consequences
in the kernel. But BUGS in the code will be as unclear as in RT mutexes.

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

Ayeh for the big...it is not that confusing :)

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