| Author |
Message |
john
Guest
|
 Posted:
Fri Jan 07, 2005 7:13 am Post subject:
Re: malloc |
|
|
Raymond Toy wrote:
| Quote: | "Jerry" == Jerry Avins <jya@ieee.org> writes:
Jerry> Stephen Maudsley wrote:
Jerry> ...
I was thinking about systems with several sources of
differeent sized
tasks with different priorities, say a conferencing controller
with
different protocols on incoming calls. Mallocing dynamic
buffers by the
call handler might be the easiest way to contain all of the
call
variable stuff in one module.
Jerry> Malloc isn't guaranteed to return a valid pointer; it can
fail. To my
Jerry> simple mind, if there's enough memory so that malloc is
sure to succeed,
Jerry> you don't need it.
To complicate things even further, even if there is enough memory
available, malloc can still fail because the malloc heap has become
fragmented and can't satisfy the request, because there's not block
large enough.
I bet the use of malloc in embedded systems is mostly a convenience.
Sometimes necessary, of course, when your embedded system is very
complex, like a cell phone with all kinds of apps. It would be hard
to allocate all the memory upfront and recycle manually.
Ray
|
Consider a multitasking O/S where each task requires some memory.
Without malloc, it will either have to be declared globally or live on
the stack of each task. Either approach allows all tasks to operate at
maximum memory utilization simultaneously, which could be unlikely in
practice. Furthermore, there can be other factors that limit the stack
size to be less than the memory needed by the task. Some stack-relative
assembler instructions have a limited reach.
John |
|
| Back to top |
|
 |
glen herrmannsfeldt
Guest
|
| Posted:
Fri Jan 07, 2005 8:01 am Post subject:
Re: malloc |
|
|
john wrote:
| Quote: | Consider a multitasking O/S where each task requires some memory.
Without malloc, it will either have to be declared globally or live on
the stack of each task. Either approach allows all tasks to operate at
maximum memory utilization simultaneously, which could be unlikely in
practice. Furthermore, there can be other factors that limit the stack
size to be less than the memory needed by the task. Some stack-relative
assembler instructions have a limited reach.
|
IBM's OS/360, and probably later OSs to, use the same routine,
called GETMAIN, for the OS to allocate memory for user tasks as
for tasks to allocate their memory.
The question left, then, is should that routine be called
malloc() or something else?
-- glen |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Fri Jan 07, 2005 10:12 pm Post subject:
Re: malloc |
|
|
john wrote:
...
| Quote: | Uptight? That's just good practice. I had a set-top digital cable box
that crashed frequently, and not checking return codes could be one of
the reasons. Another common problem in C++ systems is invoking a member
function after freeing the object. The call will succeed until the
object's memory has not been reused, but after than watch out, you
could execute the wrong code!
|
Of course it's good practice. Just say that I'm uptight enough to insist
on good practice. I'm old and crotchety enough to deplore, so I deplore
good practice's not being more nearly universal.
HLLs are supposed to abstract out the petty details of a program,
thereby organizing our thought processes and reducing errors. I consider
the gaping holes in C++ to be defects that rule out its use for any
critical application. Simplicity makes for safety. Cars can have air
bags, but the chance of falling asleep while peddling a bicycle is nil.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
Tim Wescott
Guest
|
| Posted:
Fri Jan 07, 2005 10:58 pm Post subject:
Re: malloc |
|
|
Jerry Avins wrote:
| Quote: | glen herrmannsfeldt wrote:
-- snip -- |
| Quote: | Consider a laser printer, a nice dedicated system that does the same
thing all day long. Many printers allow one to add additional RAM.
At power up it determines the available RAM and allocates it
accordingly. Once allocated it might never be free()d. The code
will be more readable calling a routine called malloc() (or any other
name one would like). It could be done other ways, but the code
would be much less readable.
Postscript does do dynamic allocation. A routine called malloc() may
or may not be a good way to do it in a Postscript (or compatible)
printer.
For the most part, I agree with you, but I think there are some exceptions.
Thanks; that makes good sense. Notice, though, that with the possibility
of expansion memory, the resources are not known at coding time.
Jerry
|
This also applies to the situation where I feel comfortable for using
malloc(): in library code where free() will never be called. I've even
implemented assign-only heaps to support this.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in