Best practice for spawning a (short) Zephyr thread from main and terminating it?

RE: Best practice for spawning a (short) Zephyr thread from main and terminating it?

nik2k — Fri, 31 May 2024 14:26:28 GMT

Thanks. My app will actually be using interrupts for handling double and long presses (using Zephyr timers). Once the presses are detected, GPIO pulses are ignored and the vibration-motor-thread is spawned. So the case that you mentioned has been covered.

RE: Best practice for spawning a (short) Zephyr thread from main and terminating it?

Susheel Nuguru — Fri, 31 May 2024 05:15:57 GMT

[quote user="nik2k"]I'm a little confused, sorry. I'm under the impression that the thread will be spawned only when k_create_thread() is called, which is enclosed within the conditional if (val == 1). [/quote]

My bad, yes, you have covered that.

Also, one small observation. It looks like you have to consider that the user might do a long button press longer than 100ms in which case the thread will be created, run and aborted more than once for one long button press. Just saying that you might need to calibrate the k_sleep time not just for spawned thread to exit but also for long button presses.

RE: Best practice for spawning a (short) Zephyr thread from main and terminating it?

nik2k — Thu, 30 May 2024 17:21:27 GMT

[quote userid="6207" url="~/f/nordic-q-a/111532/best-practice-for-spawning-a-short-zephyr-thread-from-main-and-terminating-it/486005"] seems to be a good approach to create a thread in main like you have done. It looks like the thread is created in main without any condition, so when main enters, the thread for button_pressed is created,[/quote]

I'm a little confused, sorry. I'm under the impression that the thread will be spawned only when k_create_thread() is called, which is enclosed within the conditional if (val == 1).

In my case, I am terminating without any condition and there's no cleanup since I don't have any mutexes, kernel objects or malloc-allocated memory. So I think I'm good on that part, right?

Actually I am going to be adapting this code for my application in which a newly spawned thread will pulse a GPIO pin connected to a vibration motor (for a haptic feedback), on button press. So the same application logic as here, except button_pressed() will have some gpio_pin_set_dt() and k_msleep() calls. Do you have any suggestions on what priority I could assign to such a thread? I know that the main thread has priority 0. For now, I'm using priority 5.

RE: Best practice for spawning a (short) Zephyr thread from main and terminating it?

Susheel Nuguru — Mon, 27 May 2024 10:52:05 GMT

[quote user=""]1. is this the correct approach for spawning short-lived threads? Am I forgetting to do some cleanup? and are there better approaches to use cases such as this ?[/quote]

Creation : seems to be a good approach to create a thread in main like you have done. It looks like the thread is created in main without any condition, so when main enters, the thread for button_pressed is created,

Termination : Your thread button_pressed needs to wait for something or sleep until the condition for the thread termination.

In Zephyr, a thread can terminate its execution in two ways:

1. Termination: A thread can synchronously end its execution by returning from its entry point function. This is known as termination. A thread that terminates is responsible for releasing any shared resources it may own (such as mutexes and dynamically allocated memory) prior to returning, since the kernel does not reclaim them automatically.

Here is an example of how a thread can terminate:

void my_entry_point(int unused1, int unused2, int unused3)
{
while (1) {
...
if (<some condition>) {
return; /* thread terminates from mid-entry point function */
}
...
}

/* thread terminates at end of entry point function */
}

2. Aborting: A thread may asynchronously end its execution by aborting. The kernel automatically aborts a thread if the thread triggers a fatal error condition, such as dereferencing a null pointer. A thread can also be aborted by another thread (or by itself) by calling `k_thread_abort()`. However, it is typically preferable to signal a thread to terminate itself gracefully, rather than aborting it.

Here is an example of how a thread can be aborted:

k_thread_abort(thread_id);

In both cases, once a thread has terminated, the kernel guarantees that no use will be made of the thread struct. The memory of such a struct can then be re-used for any purpose, including spawning a new thread.