On Oct 29, 2005, at 11:32 PM, MANJUNATH wrote:
Dear All,
Just I wanted to understand about exact reasons for not to include
dynamic memory allocation and function pointers in nesC.
One reason: Usage of function pointers makes deadcode elimination
difficult.
I am not able to get any other reasons......
I would request you to please give me some pointers/details about
the same...
I went through the paper "An holistic approach.."
Short answer: it leads to more reliable code.
Long answer:
Here's a pointer (haha!):
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-
February/007712.html
There's a difference between malloc() and dynamic allocation. nesC
does not forbid dynamic memory allocation: there's nothing stopping
you from writing a component that allocates a pool of memory and has
dynamic allocation interfaces. Take a look at TinyAlloc, for example.
nesC does, however, frown on malloc, for the reasons described in the
above mail. Modern coding styles generally assume unbounded memory,
in as much that you have swap space so will see tremendous
performance degradation before the system crashes. General
application behavior on allocation failure is to exit(2) and
therefore deallocate everything. With a processes, multitasking, and
automatic page reclamation, this works fine. But on an embedded
system with no memory protection, well, it's not so clean.
Part of the issue is that while dynamic allocation among a set of
cooperating components can work fine (e.g., TinyDB, Ben Greenstein
@UCLA's work on signal processing), dynamic allocation between
arbitrary components (a single shared pool) is a recipe for disaster.
One bad component can bring the entire system down, as the shared
resource breaks inter-component isolation.
The reason why nesC frowns on function pointers is because they are
dangerous and except for a few edge cases (e.g., dynamically linking
new binary modules), unnecessary. You know the call graph at compile-
time. Instead of storing a function pointer in memory, which could be
corrupted and lead you to jump to certain doom, you can just use a
parameterized interface and call based on a function ID. This also
gives you type checking for the functions It is more robust, just as
easy (once you get used to it), and generally uses less RAM (no need
to store the pointer). Function pointers are a basic result of C's
linking model. nesC's linking model does not have the same
complications (interfaces are bidirectional), so you can avoid them.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
