Re: FUSYN and RT

[Inaky Perez-Gonzalez <inaky@linux.intel.com>]

>>>>> Bill Huey (hui) <bhuey@lnxw.com> writes:

> Ok, I've been thinking about these issues and I believe there are a
> number of misunderstandings here. The user and kernel space mutexes
> need to be completely different implementations. I'll have more on
> this later.

> First of all, priority transitivity should be discontinuous at the
> user/kernel space boundary, but be propagated by the scheduler, via
> an API or hook, upon a general priority boost to the thread in
> question.

This is not necessarily true. My temperature-regulating thread should
be able to promote a task so it works around priority invertion, no
matter if they are sharing a kernel or user space lock. 

By following your method, the pi engine becomes unnecesarily complex;
you have actually two engines following two different propagation
chains (one kernel, one user). If your mutexes/locks/whatever are the
same with a different cover, then you can simplify the whole
implementation by leaps.

> With all of that in place, you do a couple of things for the mutex
> implementation. First, you convert as much code of the current RT
> mutex code to be type polymorphic as you can:

> ...

> I'd apply these implementation ideas across both mutexes, but keep
> the individual mutexes functionality distinct. I look at this
> problem from more of a reusability perspective than anything else.
 
You are talking of what is implemented in fusyn already; the only
differences are that (a) I don't use macros, but funcition pointers
(mutex ops) and (b) transitivity across user/kernel space is allowed.

> There will be problems trying to implement a Posix read/write lock

As long as the concept of rwlock allows for it to have multiple owners
(read locks need to have them), the procedure is mostly the
same. However, this not being POSIX, nobody (yet) has asked for it.

-- 

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/