Reply by Michael N. Moran●September 27, 20082008-09-27
42Bastian Schick wrote:
> On Fri, 26 Sep 2008 09:06:11 -0400, "Michael N. Moran"
> <mnmoran@bellsouth.net> wrote:
>
>>>> 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").
>> I am curious to know how having the operating system
>> handle dynamically created objects ensures safety,
>
> 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
Reply by 42Bastian Schick●September 26, 20082008-09-26
On Fri, 26 Sep 2008 09:06:11 -0400, "Michael N. Moran"
<mnmoran@bellsouth.net> wrote:
>>> 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").
>
>I am curious to know how having the operating system
>handle dynamically created objects ensures safety,
It is just, that it seems to be a common to regard dynamic objects to
be un-safe. 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.
Actually, the safe path must always be possible. If the (safety) RTOS
provides measures to handle this, even allocating of memory is safe.
(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 ... )
>or prevents problems associated with fragmentation.
Sciopta uses fixed buffer pools, which does not completly remove
fragmentation, but it is known as internal fragmentation. 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.
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
Reply by Michael N. Moran●September 26, 20082008-09-26
42Bastian Schick wrote:
> On Thu, 25 Sep 2008 17:32:14 GMT, "FreeRTOS.org"
> <noemail@given.com> wrote:
>
>> 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").
I am curious to know how having the operating system
handle dynamically created objects ensures safety,
or prevents problems associated with fragmentation.
--
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
Reply by 42Bastian Schick●September 26, 20082008-09-26
On Thu, 25 Sep 2008 17:32:14 GMT, "FreeRTOS.org" <noemail@given.com>
wrote:
>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").
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
Reply by 42Bastian Schick●September 26, 20082008-09-26
On Thu, 25 Sep 2008 05:07:32 -0500, "Jalon" <jpeeyush@gmail.com>
wrote:
>Hi All,
>
>I want to confirm my understanding on following RTOS concepts.
>
>1) There are two kind of memory management is required, one when task are
>switching and we need to allocate memory to tasks and also to place the TCB
>for switching tasks. IS it right that this memory management is done by the
>RTOS Task management feature(Not by the memory management feature).
Direct Message Passing (DMP) kernels like Sciopta (or OSE) do the
memory management as it an essential part of the RTOS.
TCBs and stacks assignment differs often from user-objects as these
are under control of the kernel.
>3) Generally in a C program execution there are two memory segments Data
>and Heap. in general Memory management means managing both or just managing
>Heap. (If only Heap then who manages Data Segment).
4 not 2, data (static), rodata (constant static), heap (dynamic) and
stack (local).
In general memory management means what the words say. But often it
applys only to the heap,i.e. dynamic memory management.
In contrast, Sciopta can be told to manage all RAM areas.
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
Reply by FreeRTOS.org●September 25, 20082008-09-25
> 1) There are two kind of memory management is required, one when task are
> switching and we need to allocate memory to tasks and also to place the
> TCB
> for switching tasks. IS it right that this memory management is done by
> the
> RTOS Task management feature(Not by the memory management feature).
There is no single way of doing this. For example, FreeRTOS.org will
automatically allocate stacks and TCB's for tasks as they are created
whereas SafeRTOS (being safety critical) does not permit dynamic memory
allocation at all so these buffers are provided statically by the
application.
> 2) Also other level of memory management is Dynamic Memory management (To
> allocate and release memory at run time). I see this is something optional
> for an application to use the Memory management feature of RTOS or write
> our own memory management feature.
They could be one and the same thing. It is difficult to come up with a
generic dynamic memory allocator for a small RTOS as different applications
have very different requirements regarding things like fragmentation
management, deterministic allocation, etc.
> 3) Generally in a C program execution there are two memory segments Data
> and Heap. in general Memory management means managing both or just
> managing
> Heap. (If only Heap then who manages Data Segment).
Again it is completely dependent on the RTOS. In most systems each task
will maintain its own unique stack, whereas heap memory will be a shared
(and hopefully protected) resource.
--
Regards,
Richard.
+ http://www.FreeRTOS.org & http://www.FreeRTOS.org/shop
17 official architecture ports, more than 6000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T�V as meeting the requirements for safety related systems.
Reply by Robert Adsett●September 25, 20082008-09-25
On Sep 25, 6:07 am, "Jalon" <jpeey...@gmail.com> wrote:
> 1) There are two kind of memory management is required, one when task are
> switching and we need to allocate memory to tasks and also to place the TCB
> for switching tasks. IS it right that this memory management is done by the
> RTOS Task management feature(Not by the memory management feature).
Not necessarily. It's fairly common for an RTOS (or rather RTK) to
push this memory allocation off to the application. I've also seem
them rely on the standard heap management for this when they were co-
operatively scheduled kernels.
Part of the answer is going to depend on what you define as an RTOS.
The term is used to cover a wide range of scales from simple single
stack systems to complex multi-process systems that dynamically load
applications from external storage.
> 2) Also other level of memory management is Dynamic Memory management (To
> allocate and release memory at run time). I see this is something optional
> for an application to use the Memory management feature of RTOS or write
> our own memory management feature.
>
> 3) Generally in a C program execution there are two memory segments Data
> and Heap. in general Memory management means managing both or just managing
> Heap. (If only Heap then who manages Data Segment).
I've always seen it as referring to the heap or rather dynamic memory
management, a lot of kernels have no concept of heap. As far as who
manages non-dynamic data it's usually the application (really the
linker and locater). And then there are the task stacks which are
managed via the mechanisms provided by 1.
The wider you define RTOS, the less emphatic you can be about any of
this.
Robert
Reply by Jalon●September 25, 20082008-09-25
Hi All,
I want to confirm my understanding on following RTOS concepts.
1) There are two kind of memory management is required, one when task are
switching and we need to allocate memory to tasks and also to place the TCB
for switching tasks. IS it right that this memory management is done by the
RTOS Task management feature(Not by the memory management feature).
2) Also other level of memory management is Dynamic Memory management (To
allocate and release memory at run time). I see this is something optional
for an application to use the Memory management feature of RTOS or write
our own memory management feature.
3) Generally in a C program execution there are two memory segments Data
and Heap. in general Memory management means managing both or just managing
Heap. (If only Heap then who manages Data Segment).
My questions clearly tell that i am a newbie in RTOS understanding. Please
provide me guidance.
Thanks,
Jalon