How to Suspend and Resume a Thread created using Iot_CreateDetachedThread?

Partners & Sponsors AWS
1

Namaste Forum Member,

My development environment comprises of ESP32 DevKitC and Amazon FreeRTOS.

For Thread creation, I’m using the Iot_CreateDetachedThread function offered by the AWS IoT Device SDK C, which has the below syntax.

bool Iot_CreateDetachedThread( IotThreadRoutine_t threadRoutine,
void * pArgument,
int32_t priority,
size_t stackSize )

Questions relating to the Thread created are:

  1. How to get the Thread Handle of this Thread for using with FreeRTOS APIs?
  2. How to Suspend and Resume this Thread, similar to the FreeRTOS APIs vTaskSuspend() and vTaskResume()?

Reference Links:

  1. AWS IoT Device SDK C - https://docs.aws.amazon.com/freertos/latest/lib-ref/c-sdk/main/index.html
  2. Iot_CreateDetachedThread - https://docs.aws.amazon.com/freertos/latest/lib-ref/c-sdk/platform/platform_threads_function_createdetachedthread.html

Thanks | Regards,
Dipen

2

Can you not use xTaskCreate instead of Iot_CreateDetachedThread? The last parameter of xTaskCreate is an output parameter to receive the created task’s handle.

Thanks.

3

And think twice before using suspend / resume a task. Often they are used the wrong way to implement certain use cases. A good sign for a potentially wrong way is suspending a task by an other task whereas resuming a self-suspended task might be ok.
Just my 2ct.

4

Thank you @aggarg and @hs2 for your prompt replies. Happy to update that I have been able to successfully compile a sample code with xTaskCreate instead of Iot_CreateDetachedThread. Functionality is working as desired.

So that brings us to the next logical question as to understanding the use case of Iot_CreateDetachedThread available as part of the AWS IoT Device SDK C.

I’ve been pondering over this and, this looks like a wrapper/ an API for creating a simple thread, for a quick task to be completed after which, it safely gets auto deleted. In case of a periodic task, the thread would be created every time, the calling function gets executed. Other thoughts?

@hs2, inputs noted. Many thanks for your 2 cents! The use-case is to self-suspend the Thread, which is then woken-up when a timeout occurs/ time-period elapses. The Thread performs its task and, again self-suspends, only to be woken-up again. Periodic job. Doing this from power saving perspective as there would be multiple threads running and, there isn’t a need for them to be continuously running. The logic explained above is working as expected. Console log is as below.

I (10240) myProgram: INFO : Inside pvMyThread()
I (10240) myProgram: INFO : Suspending pvMyThread()
I (10740) myProgram: INFO : Inside pvMyThread()
I (10740) myProgram: INFO : Suspending pvMyThread()
I (11240) myProgram: INFO : Inside pvMyThread()
I (11240) myProgram: INFO : Suspending pvMyThread()
I (11740) myProgram: INFO : Inside pvMyThread()
I (11740) myProgram: INFO : Suspending pvMyThread()

Thanks | Regards,
Dipen

5

It is a long running thread. The wrapper gives it the POSIX threading semantics of deleting itself if the function that implements the thread ever returns. Using the native API a task cannot return from its implementing function and must delete itself.

I don’t know your particular use case, but this is rarely (like almost never) the best way of achieving periodic execution. There are many other ways, such as using vTaskDelay(), vTaskDelayUntil(), or having the thread block on a direct to task notification, queue or semaphore and give the notification/queue/semaphore to unblock the task. The main issue with using suspend and resume is that it doesn’t latch - if a task runs to long and something tries to resume it before it ever got to the point of suspending itself the resume operation is missed and the task remains in the suspended state.

6

Richard is right. Of course :wink:
Although suspend sounds like saving power/resources it’s not really the case. A suspended task is more or less the same as a blocked task (e.g. in vTaskDelay).
You should consider to follow Richard’s proposal and use vTaskDelay for simple periodic tasks. It’s hard to get wrong and just works :+1:
For periodic tasks with additional input events like signaling form other tasks a timed wait e.g. using xTaskNotifyWait with timeout might be a good choice to implement periodic behavior and support communication from/with other parts of your application.

7

@rtel, I’m truly honoured to have received a reply from you :clap: #grateful

Exploring the iot_threads_freertos.c source file further brought me to the static void _threadRoutineWrapper( void * pArgument ) function, which explains the implementation.

Thank you again @rtel for suggesting the more logical and efficient methods to achieve periodic execution. Also, noted your explanation on the issues associated with suspend and resume approach.

@hs2, :heart: loved your reply #massiveRespect

And, your suggestions are noted as well.

Thanks | Regards,
Dipen

8

Namaste Forum Member,

Hope the below food for thought helps!

The thought process behind using a periodic ESP32-based Hardware timer was to run the various application-specific threads periodically.

A point to note here is that the requirement is to run periodic threads and not periodic functions.

The need for a periodic timer arises for the latter, wherein the various functions within the continuously running Embedded C-based firmware of an Embedded Systems need to execute periodically. For threads however, and specific to FreeRTOS, the periodic thread behaviour can simply be achieved using the vTaskDelayUntil() API, which blocks or suspends the thread execution for the delay time specified.

#happyToLearnThis

Thanks | Regards,
Dipen