I am running what I believe to be the latest version of Mqueue (4.24A dated
Sep 1999). I have a question about memory allocation. It would appear that
when Mqueue grabs memory for a queue, it does not return it to the OS even
if the queue is closed and removed and the memory is no longer required. It
would appear that Mqueue will reuse the memory if its requirement increases
again in the future before grabbing more from the OS. That at least is a bit
friendly. Does anybody have any knowledge of why unused memory is not
returned?
I assume Mqueue is like other QNX 4.2x components in that it never releases
memory. You have to use a library that uses shared memory if you want to use
mallocs and frees. I believe the argument is in an embedded system you should
know at the start the max amount of memory you need. The shared memory routine
is on the QNX site somewhere…
By the way someone will clarify this if necessary…
KenR
Donald Backstrom wrote:
I am running what I believe to be the latest version of Mqueue (4.24A dated
Sep 1999). I have a question about memory allocation. It would appear that
when Mqueue grabs memory for a queue, it does not return it to the OS even
if the queue is closed and removed and the memory is no longer required. It
would appear that Mqueue will reuse the memory if its requirement increases
again in the future before grabbing more from the OS. That at least is a bit
friendly. Does anybody have any knowledge of why unused memory is not
returned?
Ken Recchia <rectech@nctimes.net> wrote:
I assume Mqueue is like other QNX 4.2x components in that it never releases
memory. You have to use a library that uses shared memory if you want to use
mallocs and frees. I believe the argument is in an embedded system you should
know at the start the max amount of memory you need. The shared memory routine
is on the QNX site somewhere…By the way someone will clarify this if necessary…
Thanks Ken for all the help you have been dispensing. 
Ken is essentially correct. Freeing memory from your process and giving
it back to the system (and indeed allocating memory from the systems)
in comparison to keeping track of it locally in your process and reusing
it is relatively expensive.
It’s a compromise in favour of embeddability.
If I have the time and the answer (or part of it) I will help all I can.
Follow-up question - Is this behavior different in QRTP?
KenR
pete@qnx.com wrote:
Ken Recchia <> rectech@nctimes.net> > wrote:
I assume Mqueue is like other QNX 4.2x components in that it never releases
memory. You have to use a library that uses shared memory if you want to use
mallocs and frees. I believe the argument is in an embedded system you should
know at the start the max amount of memory you need. The shared memory routine
is on the QNX site somewhere…By the way someone will clarify this if necessary…
Thanks Ken for all the help you have been dispensing. >
Ken is essentially correct. Freeing memory from your process and giving
it back to the system (and indeed allocating memory from the systems)
in comparison to keeping track of it locally in your process and reusing
it is relatively expensive.It’s a compromise in favour of embeddability.
Ken Recchia <rectech@nctimes.net> wrote:
If I have the time and the answer (or part of it) I will help all I can.
Follow-up question - Is this behavior different in QRTP?
No… it’s the same.
Previously, Donald Backstrom wrote in qdn.public.qnx4:
I am running what I believe to be the latest version of Mqueue (4.24A dated
Sep 1999). I have a question about memory allocation. It would appear that
when Mqueue grabs memory for a queue, it does not return it to the OS even
if the queue is closed and removed and the memory is no longer required. It
would appear that Mqueue will reuse the memory if its requirement increases
again in the future before grabbing more from the OS. That at least is a bit
friendly. Does anybody have any knowledge of why unused memory is not
returned?
The other posting explain memory not being returned. When using mqueue,
you will find that the default message size and queue depth will use up
a lot of memory. In many cases one will wnat to tweak both numbers. If you
kneow that your message size is say 20 bytes, then set that when you open
the queue. You’ll save a lot of memory.
–
David L. Hawley D.L. Hawley and Associates
Once a process grabs memory in QNX4 it does not release it back to the
system pool until the process exits. It is released only to the process’s
pool for reallocation. Thus processes only grow in size. This can actually
be a good thing in embedded systems where processes quickly allocate
resources they may need and then stabilize - if several processes shared the
same memory then one of them might not get enough when required, and in an
operator-less environment that’s not nice…
Anyway - you could always try using shared/global memory (mmap etc), get the
source for mqueue off QNX’s web site and have at it… I believe Shared
memory is released back to the global pool.
A normal rule in embedded systems might be to ensure you have enough memory
for all your processes maximums…
-Paul
David Hawley <David.L.Hawley@computer.org> wrote in message
news:Voyager.001003101545.1480A@dave…
Previously, Donald Backstrom wrote in qdn.public.qnx4:
I am running what I believe to be the latest version of Mqueue (4.24A
dated
Sep 1999). I have a question about memory allocation. It would appear
that
when Mqueue grabs memory for a queue, it does not return it to the OS
even
if the queue is closed and removed and the memory is no longer required.
It
would appear that Mqueue will reuse the memory if its requirement
increases
again in the future before grabbing more from the OS. That at least is a
bit
friendly. Does anybody have any knowledge of why unused memory is not
returned?The other posting explain memory not being returned. When using mqueue,
you will find that the default message size and queue depth will use up
a lot of memory. In many cases one will wnat to tweak both numbers. If you
kneow that your message size is say 20 bytes, then set that when you open
the queue. You’ll save a lot of memory.–
David L. Hawley D.L. Hawley and Associates