9 years, 9 months ago.

Signal or restart threads?

Hey guys. I'm working on a project in which I have a "player" thread that "plays" objects containing sequences of instructions. Am I better off to start this thread at boot time and have it idle until a object comes in on a queue, or restart the thread every time there's an object to play using the thread arguments and let it terminate when it's done?

Question relating to:

Official mbed Real Time Operating System based on the RTX implementation of the CMSIS-RTOS API open standard. cmsis, rtos, RTX

1 Answer

9 years, 9 months ago.

It's usually best to have the threads be created at boot time, then sit in a "wait for signal" "do stuff" "Wait for signal" loop.

The two main reasons for this are: 1) Every individual thread uses some memory and CPU simply to exist, and the acts of creating and destroying a thread takes time to do.

2) If the order of processing matters, you'll need a queue. A small number of fixed "player" threads lets you use the built-in signal queueing. If you started a new thread every time a new object to process is generated, you risk running out of memory and "ticks", and as they'll also execute concurrently 'shorter' queues will complete first, even if they came in afterwards and so you'd need to roll your own queueing system.

Aside from that, quite a few embedded RTOS don't allow you to create new threads at runtime, so it's a good idea to get use to that idea for later projects that might use other RTOS.

Accepted Answer

Great information, thanks!

posted by Neil Thiessen 08 Jul 2014