Cube MX FreeRTOS Tasks vs Threads confusion

[TDJ]

Cube MX seems to constantly confuse FreeRTOS Tasks and Threads.

Term Tasks is being used where Threads are being actually configured.

In FreeRTOS Tasks and Threads are two different beings.

This is super confusing.

[KnarfB]

It is even more confusing if you consider that the CMSIS OS wrapper osThreadNew calls FreeRTOS xTaskCreate to do the work.

> In FreeRTOS Tasks and Threads are two different beings

Can you give a reference/definition please? The only thing I find in the The FreeRTOS™ Reference Manual are vague sentences like "Each task has its own array of pointers that can be used as thread local storage.", hmm.

KnarfB

[Pavel A.]

@KnarfB​ This is a long time confusion, maybe it stems from Intel's slang that calls "thread" a logical CPU on a processor core, as in hyper-threading. Don't know if ARM shares the same notion. The number of software threads (or "tasks") running at any time is limited to number of "hardware threads" In this terminology. While running, the state of a software thread (registers etc.) is state of some hardware thread.

[Piranha]

Those are the same thing. The general term is "thread", but unfortunately the FreeRTOS calls them "tasks" and creates a confusion. Almost everyone else, including both versions of the CMSIS-RTOS calls them "threads". As ST is using the CMSIS-RTOS API anyway, they should have used the term "thread" everywhere, but hey... we are talking about the HAL/Cube "experts" here!

Also do not confuse it with FreeRTOS Co-routines, which are going to be removed in the next FreeRTOS release anyway.

The term "task" is more appropriate for cooperative schedulers without multithreading. Setting a simple flag in a global variable is the simplest form of such.

> Intel's slang that calls "thread" a logical CPU on a processor core

Where? I haven't seen a single place where they would do that.

https://www.intel.com/pressroom/archive/releases/2001/20010828comp.htm

"The multithreading design techniques allow an operating system to view a single physical processor as if it were two logical processors."

[AScha.3]

from wiki :

Threads made an early appearance under the name of "tasks" in OS/360 Multiprogramming with a Variable Number of Tasks (MVT) in 1967. Saltzer (1966) credits Victor A. Vyssotsky with the term "thread".[3]

my view is different. yes, "thread" was some marketing idea by Intel. (Intel inside, Idiot outside. another slogan.)

i learned making programs on OS9 , multitasking/multiuser system, like Unix or later Linux, but real-time.

and it is multi-tasking , not multi threading or some "new speak" .

so i think, create new "task" is correct description for a multi-tasking system.

and in top pic "edit task" everything is correct. except you believe only in Intel marketing , but then you should use Intel products only.

but maybe it is just some historical fight between some authors or universities, hating each other and need a new name for old things from the other group. so if task is now thread - ok, maybe other name next year. not so important.

[Piranha]

@AScha.3​ , you just got it wrong and mixed up those terms. In this case it's not about some religious or marketing nonsense.

Intel's Hyper-Threading was introduced with Pentium 4 in year 2002, while NeXTSTEP (macOS), OS/2, Windows NT and POSIX Threads (BSD, Linux) had threads with that name years and decades earlier.

In desktop operating systems the "task" and "thread" just means two different things. A task is what a user does and a thread is what a kernel schedules. Therefore multi-tasking means that a user can run, for example, Notepad.exe and ping.exe simultaneously. Multi-threading means that the kernel does the context switching between the threads. Note that there can also be a multi-tasking system without multi-threading and a single-tasking system with multi-threading. Actually many of the embedded devices qualify exactly like one of those two.

[TDJ]

It is all about consistency, not tradition, marketing or history, and lack of consistency results in confusion.

FreeRTOS and ARM CMSIS RTOS2 wrapper for FreeRTOS delivered with Cube MX does differentiate Threads and Tasks. Generated code correctly includes Thread in variable names while GUI configurator mentions Tasks. It is a simple fact.

I understand that from the terminology standpoint the topic could be a matter of endless debate.

[Barry.Richard]

You can think of a FreeRTOS application as comprising of multiple threads executing in a single process. However, as FreeRTOS doesn't have the concept of processes (in the Linux sense), to avoid confusion (?) we prefer to say "tasks" instead of "threads". In a rich OS there is a difference. In an OS like FreeRTOS there is really no difference.

Thread local storage is a common phrase, with a common understanding, so we still use "thread" in that context to avoid different terminology for the same concept.

[Piranha]

> Generated code correctly includes Thread in variable names while GUI configurator mentions Tasks. It is a simple fact.

That is a fact, which proves that the same thing having two names creates a confusion!

> as FreeRTOS doesn't have the concept of processes (in the Linux sense), to avoid confusion

I cannot see how small RTOS not having processes at all creates any confusion. On the other hand calling threads, which small RTOS actually has, a tasks indeed creates a confusion. This topic is a good example of it - even after all the explanation, the topic author still thinks that threads and tasks in CubeMX are two different things...

@Barry.Richard​ , don't get me wrong - FreeRTOS is a decent product and I also use and like it. Thanks for it!