Can FreeRTOS tasks switch between detached mode and joinable mode?

In CMSIS-RTOS2 API, A thread can be created in two modes: osThreadDetached and osThreadJoinable.

In FreeRTOS I have not found any interface to set task working on osThreadDetached mode or osThreadJoinable mode.

I want to know which mode FreeRTOS tasks can support. How can I switch between osThreadDetached and osThreadJoinable?

Thanks a lot.

There is no equivalent to these posix pthread concepts in FreeRTOS, and I would say it’s rare they would be needed. What is it you are trying to achieve or implement?

Thanks. I want to implement cmsis V2.0 interface osThreadJoin and osThreadDetach. So I want to know whether there is system limitation to implement these two interfaces in FreeRTOS.

Thanks.

Why do you want to implement those interfaces - what are you trying to achieve - what problem are you trying to solve?

I looked at the definition of joinable threads briefly. Maybe something escapes me, but I can’t think of a single practical use case for them. To me it seems as if somebody thought the thing up for no other reason than that he or she could. On the down side, by definition they are prone to all kinds of problems.

Maybe you (rameble) can give us a use case that justifies its realization?

I have searched on google. I have not found use case.
Now , I attach the two interface and comment:

// Thread attributes (attr_bits in \ref osThreadAttr_t).
#define osThreadDetached 0x00000000U ///< Thread created in detached mode (default)
#define osThreadJoinable 0x00000001U ///< Thread created in joinable mode

/// Detach a thread (thread storage can be reclaimed when thread terminates).
/// \param[in] thread_id thread ID obtained by \ref osThreadNew or \ref osThreadGetId.
/// \return status code that indicates the execution status of the function.
osStatus_t osThreadDetach (osThreadId_t thread_id);

/// Wait for specified thread to terminate.
/// \param[in] thread_id thread ID obtained by \ref osThreadNew or \ref osThreadGetId.
/// \return status code that indicates the execution status of the function.
osStatus_t osThreadJoin (osThreadId_t thread_id);

According to my understanding, when threadA works in osThreadJoinable, when threadA terminate, threadA storage can not be reclaimed until another thread invoke osThreadJoin(A).

when threadA works in detached mode, when threadA terminate, threadA storage can be reclaimed immediately.

osThreadDetach, osThreadJoin these two interfaces can switch thread working mode between
detached mode and joinable mode.

well yes, that’s my understanding as well from the docs. Yet there is still little practical use imagineable. The only theoretical benefit would be non volatile TLS, but I’d argue that attempting that will buy you more problems than solutions.

Aside from that, FreeRTOS doesn’t have a concept of threads. Tasks in FreeRTOS are not meant to terminate, they typically run as infinite loops. Sometimes tasks do terminate, but that is generally one-shot asynchronous initialization. A few months ago there was somebody here thinking about dynamically creating and destroying tasks at run time as a central feature of his system, but that doesn’t fit the RTOS control flow model well. Thus, I do not see a reason to support something like detachable/joinable tasks.

FreeRTOS perfectly well handles dynamically created and destroyed tasks, at least if they do so in a controlled manner.

What FreeRTOS doesn’t have is. the dual-level concept of processes and threads which is somewhat implied by the joinable model. The idea of a ‘joinable’ thread seems to imply that these threads own some resources that the thread that joins with them can ‘inherit’ so as to pass a result. This in turn implies a level of resource management by the OS greater than what FreeRTOS provides.

Basically, FreeRTOS’s Tasks are really the ‘detached’ thread of the model, and if you need something like a ‘Joinable’ thread, you need to add code to the task to simulate that.

1 Like