I've noted a certain style of programming that makes me uncomfortable, and I'm trying to articulate why....
Some people write real time programs that rely on properties of the scheduler and the respective priorities of the threads to ensure the proper sequencing of events.
ie. We have a bit-mapped / non-preemptive scheduler where higher priority runnable threads will always run before lower priority threads.
I prefer to use messaging or synchronization primitives to guarantee that no matter which scheduler, no matter what priorities, the events will occur in the correct sequence.
What is your opinion of the matter and why?
Thanks.
Didn't find your answer? Ask the community — no account required.
T
Tim Wescott
If you can't think of any other reason to be uncomfortable about this, consider that they're counting on a side effect of the OS for correct program behavior. This is the sort of thing that may well work just peachy for years, but will be fragile and will put extra constraints on the design process.
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
V
Vladimir Vassilevsky
It depends.
The asynchronous automata are much more efficient then the syncronous automata at the average.
But, it is easier to predict and guarantee the operation for the worst case in the synchronous automata.
However, the asynchronous automata are easier to develop and maintain.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
formatting link
M
Marcin Wolcendorf
Hi,
Some thoughts from automotive (OSEK) world.
John Carter wrote:
In OSEK system (in one-task-per-priority mode) it is quite common. In this case it will even be portable!
If this will always be the case, than basing on that do not have to be a bad idea. If properly documented, that is. I would say- this is an acceptable shortcut.
Yes, but... This is more complicated approach. And in OSEK system sometimes not necessary. And sometimes you are punished heavily by OSEK implementation, if you want to use more than one 'extended' (one, that can wait for events) task - you are discouraged by OS itself. By punishment I mean- if there is only one task per priority and only the highest priority task is run and no task waits, then one can have one, common stack for all tasks. But if one wants to have tasks, that can wait for events, this is clearly not possible. The implementation then
*copies* the waiting task's stack to some storage, and copies it back to stack on task wake-up. This is *slow*.
To sum it up- synchronizing with events is cleaner, but sometimes unacceptable due to system constraints (memory, time) or project's design pattern (style). One has to adapt to requirements *and* rest of a team (or persuade others).
Regards,
M.W.
J
John Carter
Hmm. Interesting. I have worked out what's bugging me though.
The "synchronize by priorities" pattern fundamentally breaks as soon as you port to a multicore system. Because then the lower priority and the higher priority thread can run concurrently.
How does OSEK plan on handling the wave of multicore CPU's coming out now?
M
Marcin Wolcendorf
Honestly? No idea :). OSEK (+MISRA) is used for passenger/driver security related systems in automotive (probably also for engine control). Because of MISRA one can not even use dynamic memory allocation or recursion (unless heavily guarded); +5V is is still the power supply of choice and no cache is a standard. It is meant to be cheap and simple. I doubt multicore falls in that category yet :). Besides OSEK is somewhat like POSIX - specification rather than system. With multiple implementation some of which contain system extensions not covered by OSEK (and this will be probably the way, how multicore will be put into use - by some system extensions).
\begin{speculation} I see two routes here:
1) OSEK extension - the specification will be extended to embrace muticore,
2) Two cores will be used as two separate CPUs, with communication via some 'interface' (shared memory?), so you will have two OSEKs running in parallel. \end{speculation}
Regards,
M.W.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.