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.
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()
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.
Richard is right. Of course
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
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.
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.