How can delete current task/thread itself for CYW20719?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
StN__1917156
Level 4
Level 4
25 replies posted 10 replies posted 5 replies posted

I see some macro WICED_END_OF_CURRENT_THREAD(), but it is available only for 43xx platforms and cant find alternative implementation for CYW20719, so how could end the current thread from inside its implementation function body? 

Thanks

0 Likes
1 Solution

Hi Ed Pearson,

As per our software team , We don’t and cannot allow threads to be deleted. All threads the app needs must be created during initialization, and this cannot be changed.

Can you please share the application and steps to reproduce the issue which you are facing?

Thanks,

Anjana

View solution in original post

6 Replies
AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

Hello ,

Could you please check if API wiced_rtos_delete_thread  will help your purpose?

Refer the API description in wiced_rtos.h file in WICED SDK: /20719-B1_Bluetooth/include/20719/wiced_rtos.h

Thanks,
Anjana

0 Likes

Thanks for the quick response , but:

1. wiced_rtos.h (and API docs) says: wiced_result_t wiced_rtos_delete_thread( wiced_thread_t* thread );  Deletes a terminated thread.

2. In wiced_rtos API there is no any function exposed for terminating a thread

3. If we refer to ThreadX manual: "A thread is in a terminated state because another thread or the thread itself called the tx_thread_terminate service"

So in order wiced_rtos_delete_thread to work it requires first thread to be terminated and according to ThreadX documentation this could be done only through tx_thread_terminate, which means that  tx_thread_terminate need also to be exposed through wiced_rtos_* ??

0 Likes

Hi ,

I checked with our software team. The API wiced_rtos_delete_thread() is not supported. The header needs clean up.

Sorry for the confusion.

Could you please let us know , what is the reason application need to destroying a thread?

If app needs to serialize a function, you can either use wiced_app_event_serialize() or use timer APIs.

Please clarify the requirement.

Thanks,

Anjana

0 Likes

Hi,

I've had the same question.  I am also working on a 20719-B1-based project.

The reason I need to be able to delete a thread is that in our project, threads keep dying.  We don't know why, it gives no indication of error an error, it simply stops running.

For a workaround, we've created another thread, which monitors the main thread and detects when it has died.  When it dies, it starts another instance of the same thread.  Of course, this is not a permanent solution because when the thread dies, it doesn't free up its memory.

We were hoping that being able to delete the thread would free up its memory.

A better solution would be if the threads stopped dying.  We have a simple project we built, which uses very little of our code, and the main thread will still die after a few hours.

We were hoping that with WICED Studio 6.4 the issue would be resolved, but no such luck.

Suggestions welcome.

Regards,

Ed Pearson

0 Likes

Hi Ed Pearson,

As per our software team , We don’t and cannot allow threads to be deleted. All threads the app needs must be created during initialization, and this cannot be changed.

Can you please share the application and steps to reproduce the issue which you are facing?

Thanks,

Anjana

Hi Anjana,

There are many reasons and situations that would require a thread to be deleted, but most obvious one is to free memory when don’t need anymore some tasks – the memory in the microcontroller is limited, so no need to waste it in threads that don’t need any more.

Plus WICED SDK for 20719 doesn’t give tools to determine the size of the free stack, but only if stack for the task was overflowed, so no easy way to determine the optimal size of the stack when initialize a thread and in order to stay on the safe side will have to reserve more memory than what might needed!

I also don’t like in your last posting: “All threads the app needs must be created during initialization, and this cannot be changed.” Why so? A task may be needed or not needed based on interaction with the “operator” or external events, but why will have to start all the tasks at the initialization, when there is quite a chance, they will not be necessary? That is quite waste of memory real estate and I don’t know who could afford this in 20719 ☹

BTW – I started another post regarding the ThreadX – lets  hope somebody would give useful  answer as unfortunately I kick more bugs in wiced_rtos_*_event_flags  and seems the abstraction layer wiced_rtos* currently is not quite useful at all, so will have to find some alternatives - ThreadX, FreeRTOs etc…