Home > Multitasking, RTOS > Tasks or Threads: what’s in a name?

Tasks or Threads: what’s in a name?

Friday, October 2, 2009 Leave a comment Go to comments

Having spent almost my entire career in embedded and real-time software, I have become familiar with the term “task” to describe what might be called a “unit of concurrency” in a software system. Many people now use the term “thread” instead. Is there any difference? Yes and No. Here’s my take on it:

Threads (and Processes)

These two terms go back a long way and actually pre-date the term “task”. I assume that they are increasingly used in the embedded arena, these days, because of the increasing use of Linux (and to some extent, Windows) in embedded systems. For threads and processes certainly hark back at least to the early days of Unix, and subsequently the terminology has migrated, through Linux and its practitioners, into the embedded world.

“Process” generally refers to an application or a background activity running on a desktop or mainframe system. A  process may have running within it several concurrent threads. I’m not an expert on Linux internals, or those of Windows for that matter, but from my limited experience, this is how I see threads:

  • Threads typically do not manage their own resources to any great degree, but borrow them from the enclosing process.
  • Inter-thread communication facilities are often quite primitive. Such things as semaphores and shared memory (with explicit mutual exclusion) prevail. Message-passing, if it exists at all, may be confined to short, fixed-length messages with system-defined purposes.
  • Although a thread may run, in a loop, for the life of a process, it commonly does not. It is quite normal for a thread to perform some defined function, then terminate. This is neither good nor bad, but it is in direct contrast to the typical life of a task (see below).


I first came across this term in the late 70’s when Intel, for whom I was working at the time, introduced RMX80 (RMX became iRMX later on). These were the early days of RTOS, but the existing term “thread” was not used. Instead, a new term, “task” was introduced. This, I believe, was because a task was sufficiently different from a thread to warrant a new name:

  • Tasks run autonomously. Most RTOSes don’t support the concept of a process within which a task can run. Consequently, tasks need to manage their own resources directly.
  • Flexible and well organised message-passing is the norm for inter-task communication.
  • A typical task  runs in a loop from the time it is started until the power goes off. It is possible for a task to be stopped or deleted, but it is less usual for this to happen than it is for a thread to terminate within a process running, say, under Linux.

Conclusion / Prejudice

The differences are subtle, but real enough for me to prefer the term “task” when talking about RTOS. I like the name, so I’ll go on using it!

Furthermore, to use the term “thread” would only encourage those who think Linux is an RTOS. Sadly, there are many such people, though I am glad to say that they exclude honest engineers of my acquaintance who really know Linux.

Categories: Multitasking, RTOS
  1. Thursday, October 15, 2009 at 06:55

    Peter, I have used the term Task for more years than I care to remember. Only recently, as a consequence of employing younger software engineers, has the term ‘thread’ woven its way into our company vocabulary. Thanks for helping unravel the confusion (sorry! sorry!).

    I think task is more descriptive of the idea that this is something that does something, on its own cognizance, to contribute to the overall objectives of the system.

    I have recently been developing the concept of Acters. An Acter is a unit of program roughly equivalent to an object, but it contains one or more tasks (usually FSMs), some shared data an several methods to interface to the outside world. More at http://www.splatco.com/acter_model_1.htm

  2. Peter Bushell
    Thursday, October 15, 2009 at 08:07

    Thanks for your supportive comment, David. I had a preliminary look at your Acter model just now and will go back to it later.

    I have another, rather different idea for talking to multiple tasks in a structured way, but it will be a little while before it reaches this blog. I’ll let you know when!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: