Re: FUSYN and RT

[Sven-Thorsten Dietrich]

On Sun, 2005-04-17 at 22:30 -0700, Bill Huey wrote:
> On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
> > 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.
> 
> The main comment that I'm making here (so it doesn't get lost) is that,
> IMO, you're going to find that there is a mismatch with the requirements
> of Posix threading verse kernel uses. To drop the kernel mutex in 1:1 to
> back a futex-ish entity is going to be problematic mainly because of how
> kernel specific the RT mutex is (or any future kernel mutex) for debugging,
> etc... and I think this is going to be clear as it gets progressively
> implemented.
> 

PI behavior is pretty well spec'd out at this point, but its possible
to assume that no userspace locks are taken after the first kernel
lock is locked, and that the task exits the kernel without holding any
kernel locks. That makes it easier to think about, and from that
perspective, I see no complications with the transitive PI across
the user / kernel boundary.

If a userspace task has RT priority, it should be able to bump along
lower priority kernel tasks, whether they (or it) are holding any user
mutexes, or not. 

> I think folks really need to think about this clearly before moving into
> any direction prematurely. That's what I'm saying. PI is one of those
> issues, but ultimately it's the fundamental differences between userspace
> and kernel work.
> 

Bill, we are really trying to do this right, open, on the table.

This is an open invitation to anyone interested to get on the line
with us on Wednesday. Get the info for the FREE call here:

http://developer.osdl.org/dev/mutexes/


> LynxOS (similar threading system) keep priority calculations of this kind
> seperate between user and kernel space. I'll have the ask one of our
> engineers here why again that's the case, but I suspect it's for the
> reasons I've discussed previously.

Let us know, if its possible to disclose that info.

Sven


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