Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Using Pthreads in embedded Linux designs (Part 1)

Posted: 11 Jul 2014     Print Version  Bookmark and Share

Keywords:Linux  POSIX  Pthreads  API  multi-tasking 

The heavyweight "process model", historically used by Unix systems, including Linux, to split a large system into smaller, more tractable pieces does not always lend itself to embedded environments owing to substantial computational overhead. POSIX threads, also known as Pthreads, is a multi-threading API that looks more like what embedded programmers are used to but runs in a Unix/Linux environment.

This technique has been employed successfully for at least the past quarter century to build highly responsive, robust computer systems that do everything from flying space shuttles to decoding satellite TV programs. While multi-taskng operating systems have been common in the world of embedded computing, it is only fairly recently—within the past decade—that multi-tasking has made its way into the Unix/Linux world in the form of "threads"—the standard thread API known as POSIX 1003.1c, Posix Threads, or Pthreads for short.

From the perspective of an embedded systems developer familiar with off-the-shelf real-time operating systems, Linux appears to be unnecessarily complex. Much of this complexity derives from the protected memory environment in which Unix evolved. So we should start by reviewing the concept of Linux "processes". Then we'll see how threads differ, but at the same time, how the threads approach to multi-tasking is influenced by its Unix heritage.

As shown in figure 1, the basic structural element in Linux is a process consisting of executable code and a collection of resources like data, file descriptors and so on. These resources are fully protected such that one process can't directly access the resources of another. In order for two processes to communicate with each other, they must use the inter-process communication mechanisms defined by Linux such as shared memory regions or pipes.

Figure 1: Processes vs. threads.

This is all well and good as it establishes a high degree of protection in the system. An errant process will most likely be detected by the operating system and thrown out before it can do any damage. But there's a price to be paid in terms of excessive overhead in creating processes and using the inter-process communication mechanisms.

Protected memory systems are divided into User Space and Kernel Space. Normal applications execute as processes in fully protected User Space. The operating system kernel executes in Kernel Space. This means that every time a kernel service is called, read() or write() for example, the system must jump through some hoops to switch from User Space to Kernel Space and back again. Among other things, data buffers must be copied between the two spaces.

A thread on the other hand is code only. Well, ok it's code and a context, which is for all practical purposes a stack that can store the state of the thread when it isn't executing. Threads only exist within the context of a process and all threads in one process share its resources. Thus all threads have equal access to data memory and file descriptors. This model is sometimes called lightweight multi-tasking to distinguish it from the UNIX process model.

The advantage of lightweight tasking is that intertask communication is more efficient. The drawback of course is that any task can clobber any other task's data.

Historically, most off-the-shelf multi-tasking real time operating systems, such as VRTX and VxWorks, have used the light-weight multi-tasking model. Recently, as the cost of processors with memory protection hardware has plummeted, and the need for reliability has increased, many vendors have introduced protected mode versions of their operating systems.

1 • 2 • 3 • 4 Next Page Last Page

Comment on "Using Pthreads in embedded Linux des..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top