Dynamic task creation possible without using system heap?

[haunma]

I'm just getting started with FreeRTOS-Cpp and was playing with a simple example from FreeRTOS+TCP where tasks are spawned to handle each client connection to TCP port 7 (echo). In that scenario, if I understand the FreeRTOS memory scheme correctly, you can run with no system heap because FreeRTOS dynamically creates/destroys objects from its own "heap" which is actually a fixed-length array. So, it provides its own malloc/free.

So, enter FreeRTOS-Cpp. What would be the cleanest way to create FreeRTOS::Task objects as TCP connections come in? If I use new/delete, then that is engaging the system heap in addition to the FreeRTOS pseudo-heap; it also implies the objects will need to self-delete somehow at the end of their task functions. Alternatively, I could use pvPortMalloc() to get memory for the class instance. Is there any alternative I'm missing?

[jonenz]

FreeRTOS-Cpp is just a C++ 17 wrapper around the existing FreeRTOS functions. When you create task object, the constructor calls xTaskCreate and runs the normal FreeRTOS kernel function.

FreeRTOS-Cpp/FreeRTOS-Cpp/include/FreeRTOS/Task.hpp

Lines 1437 to 1443 in 5194b2e

	explicit Task(
	const UBaseType_t priority = tskIDLE_PRIORITY,
	const configSTACK_DEPTH_TYPE stackDepth = configMINIMAL_STACK_SIZE,
	const char* name = "") {
	taskCreatedSuccessfully = (xTaskCreate(callTaskFunction, name, stackDepth,
	this, priority, &handle) == pdPASS);
	}

In xTaskCreate (in the FreeRTOS kernel code), pvPortMalloc is called to allocate the stack for that task.
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/684b34ca8db0de1277b9b5359e0d1d822b53b6a2/tasks.c#L1674

This would probably be the "cleanest" way to replicate what your example is showing. There is no need to call new/delete because the task creation handles that underlying call to the kernel.

A static task (or any other static data structure in FreeRTOS) allows you to provide the memory for task stack, buffer, etc... outside of the FreeRTOS heap. The functionality that FreeRTOS-Cpp provides here is to simply take that size as a template parameter for the object and allocate the array as part of the object, so you don't have to create the array by yourself.

FreeRTOS-Cpp/FreeRTOS-Cpp/include/FreeRTOS/Task.hpp

Lines 1516 to 1520 in 5194b2e

	explicit StaticTask(const UBaseType_t priority = tskIDLE_PRIORITY,
	const char* name = "") {
	handle = xTaskCreateStatic(callTaskFunction, name, N, this, priority, stack,
	&taskBuffer);
	}

Where N is the template parameter and taskBuffer is the array allocated as part of the object size. Just be mindful of where you declare these objects so you don't put a large "static" buffer on a task's stack. If you truly want control of where this memory lies you can use the placement new operator.

Generally speaking, if you want to want to create and destroy tasks in respond to events then I would use normal task objects that have stacks on the FreeRTOS heap. If you have a known task that will exist for the lifetime of the program, then it may be good to use a static task. In general I would follow the kernel guidelines https://www.freertos.org/Documentation/02-Kernel/02-Kernel-features/09-Memory-management/03-Static-vs-Dynamic-memory-allocation.

[haunma]

Hmmm... I think I understand what you're saying, and I have looked under the hood to understand how task creation actually works. But you still need a C++ class instance for each task, don't you? And if you have tasks being created and terminated dynamically during execution, then you need to instantiate those class instances somehow when you create tasks, and delete instances when ending tasks. And those class instances have to live somewhere, no? (I normally make them global objects, but I obviously can't if I don't know a priori how many there will be.)

Contrast this to the pure C way where, because you are calling FreeRTOS functions directly, you don't need any dynamically created objects except the ones it makes for you on its own heap.

Maybe the best way to handle dynamic task creation with FreeRTOS-Cpp would be to overload new/delete to make them use pvPortMalloc() and vPortFree() instead of the system malloc/free. At least that way everything lives on one heap, instead of two.

Am I missing anything?

[electretmike]

Maybe you can use "placement new" for the allocation?

[jonenz]

Yes, the instance of the task object must live somewhere, but there isn't any reason this can't be on the stack of another task if that task is responsible for spawning new tasks. When using the normal (dynamically allocated) task object, both the TCB and stack are allocated from the heap. The base FreeRTOS::Task object itself uses very little RAM. When this object goes out of scope, the destructor will be called which in turn calls vTaskDelete.

FreeRTOS-Cpp/FreeRTOS-Cpp/include/FreeRTOS/Task.hpp

Lines 1341 to 1349 in 5194b2e

	~TaskBase() {
	#if (INCLUDE_vTaskDelete == 1)
	if (handle != NULL) {
	vTaskDelete(handle);
	}
	#endif /* INCLUDE_vTaskDelete */
	}

The FreeRTOS::StaticTask object on the other hand contains the memory for the stack, so I wouldn't recommend putting this object instance on the stack of another task unless you have a good reason to.

If that doesn't work send me the example that you're looking at and I'll see if I'm missing something.

[haunma]

That makes sense, thanks. I guess what I'm struggling with is how to create a variable quantity of tasks (of one kind) on the stack at runtime. The network code is fairly classic; a listener task is supposed to fork off connection handlers as incoming TCP connections are accept()'ed:

FreeRTOS_bind( xListeningSocket, &xBindAddress, sizeof( xBindAddress ) );
FreeRTOS_listen( xListeningSocket, xBacklog );

while (true)
{
    /* Wait for a client to connect. */
    xConnectedSocket = FreeRTOS_accept( xListeningSocket, &xClient, &xSize );

    /* Spawn a task to handle the connection. */
    xTaskCreate( prvServerConnectionInstance, "EchoServer", 640, ( void * ) xConnectedSocket, tskIDLE_PRIORITY, NULL );
}

I can't know a priori how many connection-handling tasks will be needed. (I could of course statically allocate a limited reservoir.) It seems like I need to use "new" here, and barring weird stuff like alloca(), the best I can do is to redefine new/delete to use the FreeRTOS heap functions.

I think this is the rare case where the C++ wrapper is just going to make the code less idiomatic than the original C calls :(

---

Edit: I just tried this and then realized that I'm prohibited from using new on Tasks (in TaskBase).

[jonenz]

If you want the code to look as similar as possible to the C example, then I agree with @electretmike, use pvPortMalloc to allocate the memory from the FreeRTOS heap and use placement-new to construct the Task object on that memory.

I generally wouldn't recommend using new since it the underlying code is not provided by FreeRTOS (which is probably why I deleted it). You could also patch the code to allow new if you really want to use it.