C is too old? opinions?

[Keith Thompson]

Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

My understanding is that typical garbage collection systems
occasionally through periods of intense activity to gather information
about memory that can be reclaimed. It's difficult or impossible to
predict when these periods will occur or how much CPU time they'll
take. The result can be a missed deadline, which is unacceptable in a
hard real-time system.

* Exactly how precise do you think a toaster timer needs to be?

I don't know, but if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.

Possibly garbage collection could be safely used in a toaster, but I
wouldn't use it in a real safety-critical system. (And how much
dynamic memory allocation does a toaster need to do?)

I'm not an expert on either garbage collection or real-time systems.
Feel free to correct me if I'm mistaken.

 

[pete]

You were lumping Java and .NET together, suggesting that they were
inadequate in real-time systems for the same reason.

Go on then - I would like to know how garbage collection affects
real-time systems.

http://www.devx.com/tips/Tip/13491

Many programming languages are unsuitable for real time
programming due to their non-deterministic nature. For example,
languages that have a built-in garbage collector are very problematic
because the garbage collector might "wake up" at the wrong moment,
halting all other operations until it finishes. A real time software
application that controls the amount of fuel supplied to an airplane's
engine at lift off cannot be interrupted by a garbage collector, not
even momentarily.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

* Exactly how precise do you think a toaster timer needs to be?

A toaster timer has nothing to do with real time programming.

Followup To: comp.programming

 

[Dann Corbit]

You were lumping Java and .NET together, suggesting that they were
inadequate in real-time systems for the same reason.

I was lumping them together for real time systems. Your connection was
faulty and not implied in my message.

I assumed you
must have been talking about embedded stuff as well because of your
vague reasoning and toaster example*. In other words, you seemed
confused. I made a logical leap as required.

The toaster example has nothing to do with real time systems. Your leap was
not logical.

Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

I'm full of crap and you're a genius. I can tell immediately, and there is
no sense trying to talk to you about it.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

It affects how long delays can be. That is important for real time systems.

* Exactly how precise do you think a toaster timer needs to be?

I have no idea. And it has nothing whatsoever to do with real-time
programming.

Another example of where C is an excellent choice is with DSPs and other
things of that nature. That is why you will find so many C compilers for
that arena.

If you want to write a toaster controller using embedded Java, that would be
fine

 

[Dann Corbit]

[snip]

"Real-time Java offers a much more reliable and predictable scheduling
mechanism, memory handling methods, different memory models, a more
predictable threading and synchronization model, asynchronous event
handling, and high-resolution time handling. It makes predictable
execution the first priority in all trade-off decisions, sometimes at
the expense of typical general-purpose computing performance measures.
This is what real-time means."

I predict a titanic flop. The fundamental design of Java makes garbage
collection a necessity. I just hope they don't try to steer rockets with
it.

If you delay garbage collection, yo'll run out of RAM. Who's screaming for
real-time Java anyway? They're morons.

 

[Ancient_Hacker]

Whew, "real-time" and "Java" in the same sentence.


A few gotchas:

(1) Your traditional garbage collector can really muck-up any attempts
at begin "real-time".
Real-time to a lot of folks means that the CPU can handle interrupts
and execute code at any time. Usually when you're in a
garbage-collecting phase, you're recursed down about 5 levels into some
complex object and can't just hand off to the main programas there's
lots of dangling pointers. If you can't hand off aninterrupt to code
in 5 microseconds, I'm not interested.

I'm not saying its impossible to write an interruptible garbage
collector, I just wouldnt like to haev to implement or probably, use
one.

(2) With Java you get an extreme amount of flexibility, dynamicness,
(is that a word), and security. Problem is, most real-time apps need
more "real-time" performance, and not so much of those other things.
You can't have everything. When the crunch comes, a real-time app
needs what Java can't provide, and can't be removed from the language,
and doesnt need about 60% of what's in Java.

 

[jjf]

... if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.

But ... but ... what could be worse?

 

[Dann Corbit]

Whew, "real-time" and "Java" in the same sentence.


A few gotchas:

(1) Your traditional garbage collector can really muck-up any attempts
at begin "real-time".
Real-time to a lot of folks means that the CPU can handle interrupts
and execute code at any time. Usually when you're in a
garbage-collecting phase, you're recursed down about 5 levels into some
complex object and can't just hand off to the main programas there's
lots of dangling pointers. If you can't hand off aninterrupt to code
in 5 microseconds, I'm not interested.

I'm not saying its impossible to write an interruptible garbage
collector, I just wouldnt like to haev to implement or probably, use
one.

(2) With Java you get an extreme amount of flexibility, dynamicness,
(is that a word), and security. Problem is, most real-time apps need
more "real-time" performance, and not so much of those other things.
You can't have everything. When the crunch comes, a real-time app
needs what Java can't provide, and can't be removed from the language,
and doesnt need about 60% of what's in Java.

I'm not saying it is impossible to do it either, just that it's a really bad
idea.

Consider (for instance) the Tour de France [it's a bicycle race for the
non-bike-racing folks].

Recumbent bicycles with fairings are now allowed for the time trial events.
If they were, and the stages were flat, faired recumbent bikes would smoke
the traditional diamond frames. So it is just tradition that prevents their
usage (they would be an actually superior alternative).

Suppose (for instance) that someone suggested using scooters for time
trials. You could put fairings on the scooters. And you could stand on 12
foot stilts to get a really long throw on each kick. But it's still a
scooter.

In the same way, you could tweak and munge and twist Java to make it sort of
work in a real-time environment. But it is (without question) cramming the
square peg into the round hole.

If it's not time critical, and if nobody is going to die if it should delay,
then for embedded things Java should be fine. So make toast with it, if you
like. After all, what's better than toast and Java in the morning.

 

[Morris Dovey]

(e-mail address removed) (in
(e-mail address removed)) said:

| Keith Thompson wrote:
||
|| ... if you can't guarantee a reasonable upper bound on
|| any unpredictable delays, you could end up with burned toast or
|| worse.
|
| But ... but ... what could be worse?

Setting fire to the kitchen. I'm not kidding - my ex managed to set
the kitchen curtains on fire, not just once, but _twice_ with a GE
Toast-R-Oven! Her explanation, both times, was that she'd been too
busy to pay attention...

Had to trade her in for a real-time model (no kitchen fires since.)

 

[goose]

But ... but ... what could be worse?

You drop it on the floor, it lands butter-side down

goose,
search google for an ignoble award wrt toast

 

[Mark McIntyre]

I like to have namespaces and using...

"using" is an abomination.
C++ requires headers to just the same extent as C, so any comparison
there is meaningless.
You need to step over into Java to get what you want, and frankly the
syntax there is gruesome.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Flash Gordon]

My understanding is that typical garbage collection systems
occasionally through periods of intense activity to gather information
about memory that can be reclaimed. It's difficult or impossible to
predict when these periods will occur or how much CPU time they'll
take. The result can be a missed deadline, which is unacceptable in a
hard real-time system.

Sometimes you need a predictable time interval between an external event
(generally an interrupt) and some specified action. It might not matter
whether that time is 500ns, 600ns or what, just that it does not vary by
more than some specified limit. This can be an even harder time
constraint to meet that taking at most some specific time.

If the garbage collection is on a timer interrupt, for example, you
could always just disable the interrupt during the critical period.

I don't know, but if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.
Indeed.

Possibly garbage collection could be safely used in a toaster, but I
wouldn't use it in a real safety-critical system. (And how much
dynamic memory allocation does a toaster need to do?)

I'm not an expert on either garbage collection or real-time systems.
Feel free to correct me if I'm mistaken.

It is not just safety-critical systems where this can be an issue. You
can also have hard real-time constraints on video processing and motor
control. On one of the motor control systems with interesting control
loops and IR video systems in my time, amongst other things, and none of
them were safety critical. I've also worked on one safety critical
project, and the real-time aspects where nowhere near as tight.

 

[Default User]

I predict a titanic flop. The fundamental design of Java makes
garbage collection a necessity. I just hope they don't try to steer
rockets with it.

We're looking at it very seriously for avionics systems. I wouldn't
hand-wave it away.




Brian

 

[Sjouke Burry]

You were lumping Java and .NET together, suggesting that they were
inadequate in real-time systems for the same reason. I assumed you
must have been talking about embedded stuff as well because of your
vague reasoning and toaster example*. In other words, you seemed
confused. I made a logical leap as required.

Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

* Exactly how precise do you think a toaster timer needs to be?

How precise does a feedback loop in control
need to be,when the loop goes round 1000
times per second? Even malloc/free can be
to much there.
With LISP as an example, calculating a fractal,
it stopped every 2 seconds,to do garbage collection
for 1 or two seconds.
Things just depend on how real time your
program is,and hoe short your time tick is.
If short enough,any housekeeping job can be to much,
in which case I am glad to have an old
C compiler,without those nice new features.

 

[WaterWalk]

Hi...

I am relativ new to the impressive and powerfull C language, but i
thinks it is obsolete...

The idea with header/source files where methods can clash into
eachother i don't like... Look at C# which is much cleaner with
namespaces.

Why has C not namespaces and a "area idea" where some methods and
fields could be hidden from the outside?

Something like:

a_source_file.c:

namespace SomeName(.SomeName)
{
area Stack
{
private int[] myStack;

private void someMethod() {};

public void push(int i) {};
public int pop() {};
}
}

another_source_file.c:

using SomeName(.SomeName);

int main(int argc, char[] *argv)
{
Stack.push(10);
System.printf(Stack.pop());
}

I'm really annoyed Is im the only own with that point of view?

If i was a really good programmer (which i'm not... yet! ) i would
developed a compiler and a much more simple (but still impressive and
powerfull) c...

Best and kindest regards
Lasse Espeholt

Sometime earlier, I've asked similar question about why not add
namespace to c. That thread may have something that interests you.

http://groups.google.com/group/comp...c+namespace+waterwalk&rnum=1#ded539c84ac08458

 

[Dann Corbit]

We're looking at it very seriously for avionics systems. I wouldn't
hand-wave it away.

I guess it is time to fly Airbus.
If GC happens, then things have to pause.
If GC does not happen, then memory grows uncontrollably.
I have done lots of .NET stuff, and I can tell you that it could never be
used for real-time stuff that I would trust, even if you manually call the
collector frequently. Both timing and memory size sometimes get flaky
(external routines may be out of your control, for instance). I have done a
little bit of Java (not the realtime flavor) and it behaved similarly, but I
am not nearly so expert there.

If such a thing should come to pass, I would hope and pray that (for
example) a collision avoidance system were not written in any GC language.
I would quit the job before I did that.

Of course, there may be some miracle that allows GC languages to both run GC
super-rapidly with no ballooning of memory usage.

If you really do choose such a system, I hope that you test the ever-loving
spots off of it and buy a huge insurance policy from SUN in the event that
it piles an airplane into a mountainside.

 

[Old Wolf]

"W Marsh"wrote:

How does your response relate to my post?

A toaster IC is an embedded device.

You are saying you cannot imagine .NET on a particular embedded device.

But W Marsh pointed out that Java (which is pretty much the same thing)
does run on embedded devices. In fact I am soon to be embarking
on a project to port a C application to a Java embedded device,
should be a whole barrel o' fun.

..NET started off as Java, but Sun would not let Microsoft add their own
extensions, so Microsoft forked it and renamed to .NET . They are
both garbage-collected languages that compile to a virtual machine
target.

 

[Richard Heathfield]

Dann Corbit said:

If you really do choose such a system, I hope that you test the
ever-loving spots off of it and buy a huge insurance policy from SUN in
the event that it piles an airplane into a mountainside.

By then, it's too late to buy insurance.

 

[jaysome]

Unfortunately, the FILE_H approach breaks down for files whose
names begin with "e". H_FILE is a better way from that
viewpoint.

It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

Most if not all implementations define macros in <errno.h> using a
convention that begins with an "E" followed by all uppercase
characters. The probability of a user-defined include guard macro
named something like the regular expression "E[0-9A-Z]*_H" or better
yet "E[0-9A-Z]+_H_INCLUDED_" is zero for all practical purposes.

Nevertheless, I learned something from your post as I was not aware of
the reserved "E.*" macro names. The pedantic side of me says that I
should have coded my DevStudio macro (i.e., macro in the sense of a
DevStudio script) to have used "H_FILE_INCLUDED_" instead of
"FILE_H_INCLUDED_" for the automatically inserted include guard.

Best regards

 

[pete]

jaysome wrote:

It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

That's the opposite of what the C standard says:

N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

 

[Guest]

It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

That's the opposite of what the C standard says:

N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

An external name is an identifier that has external linkage. Macros are
internal names (n1124 6.4.2.1), and E[0-9A-Z]* are only reserved as
macro names in <errno.h>.