The realtime preemption mini-summit

Still it's a practical tool and works in general.
Another problem is that most RTOSes don't have the full priority
inheritance implemented, but a simplified version.
E.g. eCos (and I think also vxworks) raise the priorities as expected,
but lower them again when all mutexes in the system are released again.
This can be very late.

The poster before said:
"that they should either not wait for potentially low priority processes
in critical paths,"

This is not easy.
I mean, assume you have code like

int get_foo(struct foo* f)
{
lock_mutex(&mutex);
memcpy(f, &source, sizeof(struct foo));
unlock_mutex(&mutex);
}

i.e. you just protect access to the variable "source". You may need this
information in a low priority thread. The code looks innocent, there are
no loops, nothing undeterministic, it will take at less than 10
microseconds.
So why now wait use the same mutex in all other threads ?
The issue is when a medium priority thread comes into play, suddenly the
code above can block a higher priority thread for a time determined by
the medium priority thread (which does not use that mutex at all).

Also, "make sure that the processes waited for already have the right
priority" is basically saying that all threads using the same mutex
should have the same priority ?
Doesn't work.

So, this is a hard issue, and there's no easy solution.
Maybe, try not to use too many shared variables, let your threads
communicate via messages/tokens/etc.
This helps, but everything gets asynchronous, which doesn't make things
necessarily easier.

Alex

But it can be done, and it is done in the current rtmutex in Linux.

From the cases he is talking about, shows me that he has not understood how to use the system at all. He does the usual mistake of not distinguishing between a mutex and a semaphore used as a condition (i.e. waiting for some external event to happen).

Yes, making an RT application work with priority inheritance mutex requires some programming rules: You can't block on a semaphore, socket etc. while holding a lock. But, heck you should always try to avoid that in any multi-threaded program to avoid the whole program eventually locking up because some message didn't arrive over TCP as expected.

In general locks should only be used "inside a module" to protect it's state. The user of the module should not be aware of it. The modules should be ordered such that low level module is not calling a highlevel module with an internal the lock taken - or you can create a deadlock. Or a even simpler rule: Newer make a call to another module with a lock held. In a RT environment with priority inheritance the module can use this to ensure the timing of all the calls to it because all the modules "lower" in the chain have a known timing and you therefore know the maximum time all the internal locks can be held by any thread.

And yes, priority inheritance takes a lot of performance. But in general you should try to avoid congestion and make your program such that the locks are not contended. The locks should only be considered as "safeguards" against a contention, which should not happen very often.

If you know how to use locks, and can avoid the pitfalls, priority inheritance will work for you - provided they are properly implemented by the OS. As is done in Linux.

Wrt. rwlocks: If a high priority, realtime writer wants the lock, it doesn't make sense to boost the readers as you don't know how many there are. What you could do was to limit the number of readers to specific number. Or you could say that writers don't boost the readers but readers can boost the single writer. That way you can't use rwlocks in real time tasks and that would not be a problem in most cases. But the kernel would need a lot of review to be sure and therefore I fully understand the current solution in the preemt RT patche.