An RTOS without Memory Managment

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.

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

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.

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.

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.

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.

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.

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.

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 ... )

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.

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.

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?

... and designed into the *application*.

What measures will the RTOS provide?

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?

Internal to what? To the RTOS? To a particular buffer pool?

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?