User: Password:
|
|
Subscribe / Log in / New account

The realtime preemption mini-summit

The realtime preemption mini-summit

Posted Sep 29, 2009 18:14 UTC (Tue) by aleXXX (subscriber, #2742)
In reply to: The realtime preemption mini-summit by abacus
Parent article: The realtime preemption mini-summit

Yes, it's messy.

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


(Log in to post comments)

The realtime preemption mini-summit

Posted Sep 29, 2009 20:09 UTC (Tue) by michaeljt (subscriber, #39183) [Link]

> 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);
> }
That particular example could be solved by RCU, although I don't want to start a showdown here, as I'm sure you would win it :) I was thinking more on the lines of avoiding contention in the critical path as much as possible though.

The realtime preemption mini-summit

Posted Oct 11, 2009 16:02 UTC (Sun) by efexis (guest, #26355) [Link]

Priority inheritance may often/usually not be the best way to do things by design (ie, try not to rely on it) sure, but is always better to have support for it to avoid inversion just-in-case, than not and have a Pathfinder style incident on your hands :-)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds