Re: An RTOS without Memory Managment
- From: "Michael N. Moran" <mnmoran@xxxxxxxxxxxxx>
- Date: Fri, 26 Sep 2008 23:01:31 -0400
42Bastian Schick wrote:
On Fri, 26 Sep 2008 09:06:11 -0400, "Michael N. Moran" <mnmoran@xxxxxxxxxxxxx> wrote:
I am curious to know how having the operating system handle dynamically created objects ensures safety,whereas SafeRTOS (being safety critical) does not permit dynamic memory allocation at all so these buffers are provided statically by the application.That´s why e.g. Sciopta handles the dynamic objects,
so their use is safe (with regard to "safety
critical").
It is just, that it seems to be a common to regard
dynamic objects to be un-safe.
Dynamic object "allocation" is not inherently unsafe,
but using a general purpose heap with the expectation
that it will not fragment over time *is* unsafe.
Pretending that an operating system can hide
memory allocation from the application and make
the application safe is crazy talk.
There is no substitute for an application knowing
its resource limitations and operational requirements,
and explicitly handling all resource allocation
exceptions ... assuming the application is to perform
its function safely with no possibility of failure due to
software failure.
I believe, if the RTOS is written with saftety in mind
(as SCIOPTA is), creating and killing objects (i.e.
memory or tasks, or groups of tasks) will not impose an
unsafe situtation.
How can an RTOS provide this guarantee? How can the
RTOS know the safe action to take in the face of
any particular allocation failure?
Actually, the safe path must always be possible.
.... and designed into the *application*.
If the (safety) RTOS provides measures to handle this,
even allocating of memory is safe.
What measures will the RTOS provide?
(I am not sure if I could express it right ..., anyhow
this is about Sciopta, a DMP kernel w/o shared memory,
w/o heap ... )
I assume you mean that the RTOS itself does not use
shared memory or the general purpose heap.
What is your definition of "shared memory"?
Memory shared between processors?
Memory shared between processes?
or prevents problems associated with fragmentation.
Sciopta uses fixed buffer pools, which does not completly
remove fragmentation, but it is known as internal
fragmentation.
Internal to what? To the RTOS? To a particular
buffer pool?
But internal fragmentation will not lead to an "out of
memory" situations as on returning memory, the whole
buffer is available for the next allocation.
Is this because all of the buffers in a given pool
are of a fixed size?
What happens if an application uses the RTOS service
and all of the "buffers" in the pool are unavailable?
Is the application notified when a buffer becomes
available such that the application logic can take
action on the *event* that memory has become available?
Without blocking?
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)
The Beatles were wrong: 1 & 1 & 1 is 1
.
- References:
- An RTOS without Memory Managment
- From: Jalon
- Re: An RTOS without Memory Managment
- From: FreeRTOS.org
- Re: An RTOS without Memory Managment
- From: 42Bastian Schick
- Re: An RTOS without Memory Managment
- From: Michael N. Moran
- Re: An RTOS without Memory Managment
- From: 42Bastian Schick
- An RTOS without Memory Managment
- Prev by Date: Re: 40 core embeddified processor
- Next by Date: Bvlgari Assioma Watches - Bvlgari Watches Discount Price
- Previous by thread: Re: An RTOS without Memory Managment
- Next by thread: Re: An RTOS without Memory Managment
- Index(es):
Relevant Pages
|
Loading