Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2

[Esben Nielsen]

On Wed, 1 Dec 2004, Paul Davis wrote:

> [...]
> >
> >> futexes are nearly lock-free. [and even those locks are short-held so
> >> combined with priority-inheritance they should be lockfree in
> >> essence.] Would futexes suit your purposes?
> >
> >to which suggestion i got no reply yet :-)
> 
> i am still trying to find the time to investigate futexes. they seem
> close to the desired object, but have a slightly more general semantic
> than i can fit into my head right now;)
>

I looked into them just to see if they could be used for user-space
priority inheritance. I saw that it takes (read-)lock on mmap_sem.
Isn't that potentially held for a long time? I don't know how the memory
subsystem works at all but my guess is that any changing of the process's
memory is done with mmpa_sem locked. The only way to prevent that is 1)
mlockall() and 2) stop increasing your heap.

I.e. you can't have one thread running real-time using a futex while
another runs non-real-time allocating memory in the same process.

Am I correct?

Another problem is the hashing of the futex. That inherently has a
non-deterministic timing behaviour. The more applications use futex'es
the slower this hashing gets :-( The slowdown might in practise be very
low because looking up in the global hash table can't take very many us!

Can't it just use a file-descriptor in the system call to look up the
futex instead of the hashing? That is RT-O(1), right? But, ofcourse, then
it is hard having a futex in shared mem.

 
> --p

Esben

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