Multithread support in freeRTOS

[N-K1998]

Issue template

• Hardware description: STM
• RTOS: freeRTOS
• Installation type: microros_setup
• Version or commit hash: iron

I am building an application with different tasks running in FreeRTOS. An application with one publisher in one task and the subscribers in the main one. My question is what the multithread support do? Does it simply add the feature of making the library thread-safe? In the context of a custom transport, is it possible to have different threads running the code of the transport layer? If you can provide some documentation about this feature it could be very useful.

Thank you

[pablogs9]

It simply makes the micro-ROS middleware thread-safe, be careful because that does not mean that all RCL / RCLC APIs are thread-safe. Check the documentation for each one on the corresponding API doc.

Here you have documentation: https://docs.vulcanexus.org/en/latest/rst/microros_documentation/user_api/user_api_multithreading.html

[N-K1998]

Ok, thank you. Do the executors block the freeRTOS scheduler even in the multithreaded version of microros?

[pablogs9]

Not sure what means "block the FreeRTOS scheduler". The executor spin is a function call that will no yield / sleep to the scheduler. So if the task with the higher priority calls spin() forever it won't let other tasks run.

[N-K1998]

I was referring to one of your answers in the previous issues: "Avoid using rclc_executor_spin in embedded systems, it can freeze your scheduler.

Use this approach:

while(1){ delay execution for letting other tasks to run spin some the rclc executor }"

So it can freeze the scheduler if it is executed in the higher priority task.

[pablogs9]

rclc_executor_spin will not return if everything goes normal. That means that if you run rclc_executor_spin in the highest priority task, other tasks won't be executed.

Maybe "freeze" is not the most proper way of saying that the scheduler will prioritize the highest priority task's workload.

So, the approach shall be:

while(1){
  delay execution for letting other tasks to run
  spin some the rclc executor
}

[N-K1998]

Ok perfect, last question. Supposing to have a custom transport, the custom functions will only be called in the thread/task where the rmw_uros_set_custom_transport has been called right? I mean, there are no task/thread creations for each task using rcl_publish or using executors.

[pablogs9]

Internally the micro-ROS stack does not create any thread/task in any case.

rmw_uros_set_custom_transport just sets the required callbacks for the transport operation.

The transport callbacks will be called when required:

• If a thread/task publish, it will probably use the write operation of the transport
• If a thread/task spins an executor, it will probably write and read to and from the transport

But, those transport API are protected from multithread operation with the micro-ROS Thread Safe mode.

[N-K1998]

Where can I find a transport implementation that works with multithreading? Just to understand how it should be implemented.

[pablogs9]

all transport implementations are thread-safe if the library is configured as thread safe. The library uses the transport API in a thread safe way.

[N-K1998]

I understand, thank you.