c++ polymorphism and real-time programming

[Mike Wahler]

Hi.

Can anyone refer me to any articles about the compatibility between
c++ polymorphism and real-time programming?

Um, www.google.com ??

I'm currently on a real-time c++ project, and we're having a
discussion about whether we should allow polymorphism. Our system is
not embedded and does not need to be as real-time as, say, a
pacemaker. But it does involve updating displays based on radar
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

I don't think 'real time' should affect such a decision.
Let your model determine that. I don't see anything
preventing a real-time system written in C++ from using
polymorphism. The real question is, is polymporphism
suitable for modeling your application?

-Mike

 

[Ken]

Hi.

Can anyone refer me to any articles about the compatibility between
c++ polymorphism and real-time programming?

I'm currently on a real-time c++ project, and we're having a
discussion about whether we should allow polymorphism. Our system is
not embedded and does not need to be as real-time as, say, a
pacemaker. But it does involve updating displays based on radar
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

Thanks,

Ken

 

[David White]

Hi.

Can anyone refer me to any articles about the compatibility between
c++ polymorphism and real-time programming?

I'm currently on a real-time c++ project, and we're having a
discussion about whether we should allow polymorphism. Our system is
not embedded and does not need to be as real-time as, say, a
pacemaker. But it does involve updating displays based on radar
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

I'm not aware of any. I don't see how the decision to use polymorphism is
influenced by real-time projects. I am aware of one EPROM project in my own
workplace that is very much real-time and uses polymorphism frequently. It
would help if you could explain why you believe your decision to use
polymorphism is affected by the project's real-time nature.

DW

 

[Gianni Mariani]

Hi.

Can anyone refer me to any articles about the compatibility between
c++ polymorphism and real-time programming?

I'm currently on a real-time c++ project, and we're having a
discussion about whether we should allow polymorphism. Our system is
not embedded and does not need to be as real-time as, say, a
pacemaker. But it does involve updating displays based on radar
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

Thanks,

Ken

Polymorphism is implemented in a way that is very predictable wrt run
time and hence there is a very predictable impact for "real time"
requirements.

Depending on what you're doing, it can also increase performance
relative to straight line code.

Hence, create a good design, if polymorphism solves some problems neatly
then you're doing better than most !

I've regulary used polymorphism with no impact in real time systems.

G

 

[E. Robert Tisdale]

Can anyone refer me to any articles about the compatibility
between C++ [run-time] polymorphism and real-time programming?

I'm currently on a real-time C++ project and we're having a discussion
about whether we should allow [run-time] polymorphism.
Our system is not embedded
and does not need to be as real-time as, say, a pacemaker.
But it does involve updating displays based on radar input.
So a need for something close to real-time is desired
(how's that for non-deterministic requirements? ).
However, we'd like to have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

Real time programming requires only that
a code will complete execution within a specified amount of time.
Run-time polymorphism won't prevent your code from doing that.
What you need to be careful about is things like
memory allocation from the free store
which can take more or less time depending upon how quickly
the memory allocator can find a fragment that is large enough.

 

[foo]

Hi.

Can anyone refer me to any articles about the compatibility between
c++ polymorphism and real-time programming?

I'm currently on a real-time c++ project, and we're having a
discussion about whether we should allow polymorphism. Our system is
not embedded and does not need to be as real-time as, say, a
pacemaker. But it does involve updating displays based on radar
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

Thanks,

Ken

There are two forms of polymorphism in C++.
dynamic polymorphism
static polymorphism

dynamic polymorphism is implemented via inheritance
static polymorphism is implemented via templates

static polymorphism is generally potentially faster then dynamic
polymorphism.

However, just because you have a real-time requirement, doesn't mean
you have to rule out dynamic polymorphism all together.
It depends where your code spends the most time at.

 

[Tim Clacy]

Hi.
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

The mechanisms used to acheive polymoprhism are deterministic and have
little overhead (an extra level of indirection). More importantly, it helps
you more easily implement clear, concise software models... and, at the end
of the day, that's what this game is all about (as you know, of course). The
only C++ language features that are non-deterministic and, therefore should
be avoided like the plague in embedded, real-time software are RTTI and C++
exception handling; this also means steering clear of STL in most cases.
Neither RTTI and C++ exception handling help abstraction and you can roll
your own lean mean exception-safe templates for useful types like queues,
stacks and brethren... if you ask me.


Tim

 

[Peter van Merkerk]

The mechanisms used to acheive polymoprhism are deterministic and have
little overhead (an extra level of indirection).

Also consider the alternatives for polymorphism; for example using
switch-case or if statements might result in less determinisic behaviour
compared to the polymorphism approach.

The only C++ language features that are non-deterministic and, therefore
should be avoided like the plague in embedded, real-time software are
RTTI and C++ exception handling; this also means steering clear of STL
in most cases.

Besides those dynamic memory allocation is typically non-deterministic
as well. It is difficult to predict how long a new or delete will take.
For real-time system it is usually a good idea to pre-allocate needed
memory in advance.

Another factor that makes deterministic response times difficult to
achieve on modern platforms are things like processor cache, branch
predication logic, parallel execution of instructions, busmaster
DMA...etc. When using virtual memory all bets are of. Thanks to all
these goodies there can be a huge difference between the worst case
scenario and the typical case. Algorithm complexity specifications may
mean very little in terms of absolute time. For example a linear search
of a small vector may actually be more deterministic than using a map,
because a vector typically keeps the elements close together in memory,
which reduces the chance of cache misses. To avoid non-deterministic
behaviour due to caching, some processors allow you to explicitly
specify what should be cached or not. However all that is way beyond the
scope of standard C++

 

[Ian]

The mechanisms used to acheive polymoprhism are deterministic and have
little overhead (an extra level of indirection). More importantly, it helps
you more easily implement clear, concise software models... and, at the end
of the day, that's what this game is all about (as you know, of course). The
only C++ language features that are non-deterministic and, therefore should
be avoided like the plague in embedded, real-time software are RTTI and C++
exception handling; this also means steering clear of STL in most cases.
Neither RTTI and C++ exception handling help abstraction and you can roll
your own lean mean exception-safe templates for useful types like queues,
stacks and brethren... if you ask me.

If exceptions are used where they are supposed to be used (exceptional
conditions) that fact that they aren't deterministic is less of a worry.
The condition its self will make the execution non deterministic.

If you are going to avoid exceptions and the STL, you may as well use EC++.

Ian

 

[Tim Clacy]

If exceptions are used where they are supposed to be used (exceptional
conditions) that fact that they aren't deterministic is less of a
worry. The condition its self will make the execution non
deterministic.

Exceptions have a run-time overhead whether they're used or not.
Furthermore, they often seem to be used to avoid having to check results of
operations which makes things very non-deterministic. Personally, I would
rather use design-by-contract design-time testing to avoid situations that
could cause exceptions and actually deal with results from operations that
could fail; it's just a matter of discipline. If you're not careful, C++
exception soon become lazy-mans error checking; jusdging by the number of
times applications under XP dies and generate error reports, C++ exceptions
don't improve robustness (the assumption here is that most desktop
applications these days make widespread use of exceptions/STL). Of course,
this is only my opinion.

If you are going to avoid exceptions and the STL, you may as well use
EC++.

I beg to differ; for instance, namespaces help structure code and libraries
but are not part of EC++. Templates offer some very neat tricks for
efficient, typesafe ADTs and template metaprogramming enables extremely
efficient code generating trick; again, not available in EC++. Typical
embedded applications don't need the full STL monty and can't afford the
risk of C++ exceptions; it's no effort to roll a typesfae, robust queue,
list, iterator and the benefit of being totally in control of run-time
behaviour and code-size outways the effort of half a page of source (again,
only my opinion).


Tim

 

[Peter van Merkerk]

If exceptions are used where they are supposed to be used
(exceptional

Exceptions have a run-time overhead whether they're used or not.

That depends on the implementation. Even if exceptions have a run-time
overhead when they are not thrown, in the context of a real-time system
the real question is: is the overhead deterministic? On some
implementations exceptions have zero runtime overhead when they are not
thrown. On those implementations it might actually be faster to use
exceptions that to check the error status after every function call and
to propagate the error code back to the caller.

However when an exception is thrown we have different story. In a
real-time system you don't want exceptions to be thrown during normal
operation.

Furthermore, they often seem to be used to avoid having to check results of
operations which makes things very non-deterministic.

I fail to see the logic here. Errors reported by return values or some
error variable can be easily ignored, ignoring exceptions requires extra
effort from the programmer. Considering this, I come to the opposite
conclusion.

Personally, I would
rather use design-by-contract design-time testing to avoid situations that
could cause exceptions

Unfortunately not all exceptions can be replaced by DbC.

and actually deal with results from operations that
could fail; it's just a matter of discipline.

Either way you will need discipline (as always with C++). If you don't
use exceptions the error status must be checked after every function
call and propagated which is tedious and easy to forget. With exceptions
the RAII idiom must be applied when actions have to be undone in case of
an error.

If you're not careful, C++
exception soon become lazy-mans error checking; jusdging by the number of
times applications under XP dies and generate error reports,

That has little to do with exceptions and a lot with poor programming. I
bet a lot of those error reports have little or nothing to do with
exceptions.

C++ exceptions
don't improve robustness (the assumption here is that most desktop
applications these days make widespread use of exceptions/STL).

That assumption may be wrong. But even if it were right; what do you
think what would happen without exceptions? The best you can hope for is
that it fails silently with without malicious side effects.

Not handling exceptions falls into the same category as ignoring error
return values. The difference is that if you fail to handle a exception
the application will terminate, if fails to act on a return code the
application will hop along untill it crashes somewhere else. In both
cases the problem is the programmer, not the error reporting/handling
strategy.

I don't think exceptions are the root of all evil; they are often just
the messenger with bad news. OTOH I don't want to advocate using
exceptions as a better alternative to return codes. Sometimes return
codes are a more appropriate/better choice. It depends on the situation,
understanding the pros and cons is the key here.

 

[Tim Clacy]

That depends on the implementation. Even if exceptions have a run-time
overhead when they are not thrown, in the context of a real-time
system the real question is: is the overhead deterministic? On some
implementations exceptions have zero runtime overhead when they are
not thrown. On those implementations it might actually be faster to
use exceptions that to check the error status after every function
call and to propagate the error code back to the caller.

However when an exception is thrown we have different story. In a
real-time system you don't want exceptions to be thrown during normal
operation.


I fail to see the logic here. Errors reported by return values or some
error variable can be easily ignored, ignoring exceptions requires
extra effort from the programmer. Considering this, I come to the
opposite conclusion.


Unfortunately not all exceptions can be replaced by DbC.


Either way you will need discipline (as always with C++). If you don't
use exceptions the error status must be checked after every function
call and propagated which is tedious and easy to forget. With
exceptions the RAII idiom must be applied when actions have to be
undone in case of an error.


That has little to do with exceptions and a lot with poor
programming. I bet a lot of those error reports have little or
nothing to do with exceptions.


That assumption may be wrong. But even if it were right; what do you
think what would happen without exceptions? The best you can hope for
is that it fails silently with without malicious side effects.

Not handling exceptions falls into the same category as ignoring error
return values. The difference is that if you fail to handle a
exception the application will terminate, if fails to act on a return
code the application will hop along untill it crashes somewhere else.
In both cases the problem is the programmer, not the error
reporting/handling strategy.

I don't think exceptions are the root of all evil; they are often just
the messenger with bad news. OTOH I don't want to advocate using
exceptions as a better alternative to return codes. Sometimes return
codes are a more appropriate/better choice. It depends on the
situation, understanding the pros and cons is the key here.

I agree with averything that you've said and, as I said, my comments were my
own personal opinion. However, I prefer loosely coupled components
interacting through queues to tightly coupled components interacting through
a stack; perhaps it's because I do a lot of device driver, mixed
hawrdware/software and bus based development. Here you can't afford to
ignore transaction codes; ´C++ exception are only really practical in
traditional simple-minded, single processor 70's view of 'programs'. Yes, I
know you can throw exceptions across process boundaries and machine
boundaries... but it ain't pretty. Besides, once you get used to concurrent
event-driven automata interacting through event queues, you simply don't
have these kind of head-aches anymore... ofcourse, just my opinion


Tim

 

[Novice]

The mechanisms used to acheive polymoprhism are deterministic and have
little overhead (an extra level of indirection). More importantly, it helps
you more easily implement clear, concise software models... and, at the end
of the day, that's what this game is all about (as you know, of course). The
only C++ language features that are non-deterministic and, therefore should
be avoided like the plague in embedded, real-time software are RTTI and C++
exception handling; this also means steering clear of STL in most cases.

Just wanted to clarify a point here.

When you say the mechanisms used to acheive polymoprhism are deterministic
and have little overhead are you talking about things like when virtual
tables are used for determining which member function should actually be
getting invoked?

Then when you talk about RTTI are you talking about calls to things like the
function typeid?

Thanks,
Novice

[snip]

 

[Adam Fineman]

Can anyone refer me to any articles about the compatibility
between C++ [run-time] polymorphism and real-time programming?
<snip>

Real time programming requires only that
a code will complete execution within a specified amount of time.

Exactly. Real-time doesn't mean "real fast," it means "real predictable."

Run-time polymorphism won't prevent your code from doing that.
What you need to be careful about is things like
memory allocation from the free store
which can take more or less time depending upon how quickly
the memory allocator can find a fragment that is large enough.

And whether or not pages are swapped while the application is running.
And whether or not you've got unbounded priority inversions. And
whether or not you have unacceptable periods when interrupts are
disabled. And so on.

In other words, run-time polymorphism may well be the least of your
concerns, if it's a concern at all. Generally, the overhead induced by
polymorphism can be bounded. Real-time programmers should be concerned
about unbounded latencies.

- Adam

 

[Gianni Mariani]

Can anyone refer me to any articles about the compatibility
between C++ [run-time] polymorphism and real-time programming?
<snip>

Real time programming requires only that
a code will complete execution within a specified amount of time.

Exactly. Real-time doesn't mean "real fast," it means "real predictable."

YES - you are 100% correct.

However for most people that want "real(very) fast" code usually
(practically allways) want "real(very) predictable" as well.

And whether or not pages are swapped while the application is running.
And whether or not you've got unbounded priority inversions. And
whether or not you have unacceptable periods when interrupts are
disabled. And so on.

Priority invesions ! That's the first time I've heard that term. I
suspect it means that the priority of a thread that attains a resource
is sometimes lower than the thread waiting for a resource and hence the
thread that with the higher priority undesirably waits for a thread with
lower priority. I've used "priority inheritance" to describe this
scenario. A significant problem for multi-threaded real-time systems.

In other words, run-time polymorphism may well be the least of your
concerns, if it's a concern at all. Generally, the overhead induced by
polymorphism can be bounded. Real-time programmers should be concerned
about unbounded latencies.

Exactly. I know of no C++ implementation whose polymorphic mechanisms
fail the real-time requirements. If polymorphism solves a problem, in
most cases it solves the problem in a very fast and maintainable way as
well.

 

[Gianni Mariani]

Just wanted to clarify a point here.

When you say the mechanisms used to acheive polymoprhism are deterministic
and have little overhead are you talking about things like when virtual
tables are used for determining which member function should actually be
getting invoked?

Then when you talk about RTTI are you talking about calls to things like the
function typeid?

And dynamic_cast<>()

Try to avoid dynamic_cast<>(), if you structure you code correctly,
theye is no need for it.

 

[Adam Fineman]

Adam Fineman wrote:

Priority invesions ! That's the first time I've heard that term. I
suspect it means that the priority of a thread that attains a resource
is sometimes lower than the thread waiting for a resource and hence the
thread that with the higher priority undesirably waits for a thread with
lower priority.

That's essentially it. A priority inversion is when a higher-priority
task has to wait for a resource that is held by a lower-priority task.
This is only a problem in real-time systems when the priority inversion
is unbounded (i.e. not predictable) in duration. (Incidentally, an
unbounded priority inversion is what caused the Mars Pathfinder to fail.)

I've used "priority inheritance" to describe this
scenario. A significant problem for multi-threaded real-time systems.

"Priority inheritance" is actually a term describing one possible
solution to unbounded priority inversions. Essentially, the
lower-priority task "inherits" the priority of the higher-priority task
as soon as the higher-priority task blocks. After the lower-priority
task releases the resource, it is rescheduled at its original priority.

Another possible solution to unbounded priority inversions is known as
"priority ceiling protocol emulation." In this case, any task holding a
resource is temporarily elevated to some ceiling priority until it
releases the resource.

- Adam

 

[Ian]

I agree with averything that you've said and, as I said, my comments were my
own personal opinion. However, I prefer loosely coupled components
interacting through queues to tightly coupled components interacting through
a stack; perhaps it's because I do a lot of device driver, mixed
hawrdware/software and bus based development. Here you can't afford to
ignore transaction codes; ´C++ exception are only really practical in
traditional simple-minded, single processor 70's view of 'programs'. Yes, I
know you can throw exceptions across process boundaries and machine
boundaries... but it ain't pretty. Besides, once you get used to concurrent
event-driven automata interacting through event queues, you simply don't
have these kind of head-aches anymore... ofcourse, just my opinion

While throwing across boundaries ain't pretty, it is often very useful
in distributed RT applications. In my opinion, one has to make the call
up front to throw or not to throw. I tend to prefer the throw route,
once I have confirmed that there is no unnecessary overhead in the
normal case.

If the code then scales to a multi CPU target, the same logic applies.

I haven't used any compilers that do introduce a time over head for
exceptions, but there is often a space one due to extra stack sizes.

Ian

 

[Peter van Merkerk]

Hi.

Can anyone refer me to any articles about the compatibility between
c++ polymorphism and real-time programming?

I'm currently on a real-time c++ project, and we're having a
discussion about whether we should allow polymorphism. Our system is
not embedded and does not need to be as real-time as, say, a
pacemaker. But it does involve updating displays based on radar
input. So a need for something close to real-time is desired (how's
that for non-deterministic requirements? ). However, we'd like to
have the design benefits of polymorphism.

Any opinions or references to articles would be greatly appreciated.

http://www.objectmentor.com/resources/articles/WhyAreYouStillUsingC.pdf

 

[shuvro_sabbir]

Realtime programming in C++

Hello everyone,

I will be glad if anyone give me some guideline or guide me with some valuable information about real time programming in C++..