Multi-Thread or Multi-Process?

So 2.6.28 is here and so are a few very nice features.

ext4 with improved journaling, larger maximum capacity and an increase in speed. This update also means that ext3 can be updated to ext4 with minimal work as ext4 is backwards compatible.

Boot Tracer, something Wind River had in our previous and next release, has just made it to the Kernel. Now you can see what is taking the time during the boot and optimize it out.

taint_crap! New for the source tree to manage development drivers. This is moving all the *unstable* drivers currently in development into a staging area.

All this plus much much more!

Enrico Salvatori, Senior VP Qualcomm Europe, talks to Electronics Weekly about the impact of open source on mobile phone design.

Linux has supported Symmetrical Multi-Processor (SMP) environments for many years. Until recently this has mainly benefitted server class applications but increasingly multi-processor and multi-core systems are found in embedded systems.

To make best use of SMP, each application needs to be developed in a way which exploits the parallel execution capabilities.

Linux offers both a process and thread model but which should you use?

Programmers with a background in UNIX application development will naturally develop using processes. Those coming from an embedded background, having used Real-Time OS’s (RTOS), will be more inclined to use tasks (threads).

From the Linux kernel point of view there is very little difference between processes and threads. But those few differences are important.

So what is a process? Simply put it is a container for an executable object, an application. Each process has a single, sequential, flow of execution (code) and its associated data. Every process is protected from every other process in the system by the kernel using a Memory Management Unit (MMU). Since each process is independent of the others the kernel can schedule several to execute in parallel when there are several CPUs or cores to schedule on.

Threads enhance the process model with multiple, parallel, flows of execution within a process. All threads within a process share the same memory space.

The kernel treats threads as separate and independent entities so it can schedule several threads to run in parallel, just as it can with complete processes.

So the key difference between processes and threads is the way memory is managed. This has several implications, the two of the most most important are:

  • Inter-thread communication is fast
  • There is no protection between threads

Since processes do not naturally share memory it is difficult for one process to communicate with another. Several Inter-Process Communications (IPC) methods exist but they all rely on passing data via some intermediary such as the file system or network stack. Ultimately the kernel manages communications between them.

Threads, on the other hand, can communicate directly using shared memory objects such as arrays of data (buffers).

The disadvantage of threads is the classic problem faced by engineers used to RTOS’s and that is the fact that a bug in one thread can corrupt the memory being used by another thread. When a thread crashes it is natural to start debugging that thread but it may well be that the bug is in code utilised only by another thread. These issues can be very difficult to track down!

So when designing an application to exploit the parallel capability of hardware it may seem that the decision is one of performance over protection and debug-ability. But it is not always so simple.

You could have a fast web server, making heavy use of the threaded capability of the OS, but it is unlikely that you will have many customers if they are running an on-line sales system. Why? Simply that any exploitable defect could enable an attacker to read the credit card data from another user – remember that the memory for the thread handling that transaction is readable by the thread handling the attackers connection.

Processes fit the compartmentalisation philosophy presented in many security manuals.

On the other hand you could have a very secure multi-process application for process control, but if the overhead of communications is too high then you could end up with actuators overshooting their targets. Potentially very damaging.

So the correct balance has to be struck between security and performance and this will require some analysis of the application and the performance capabilities of the hardware. One benefit of Linux is you can chose to use a combination of both processes and threads in a single system. Such a hybrid design can give the optimum balance between speed and security.



  1. I am monitoring a commercial app that the vendor claims is multithreaded. The software is running on a four-processor machine, but the process is fully utilizing a single processor. Does Linux schedule threads in parallel across processors? If so, how can I determine why the process is only using a single CPU? Thanks!

  2. Actually, in most Unixes and I think also in Linux processes can arrange to share memory. You need to use the IPC calls to create a named shared memory segment at a fixed virtual address range in each process. (ability to attach to a segment has a security model similar to basic file security permissions)
    The kernel maps the virtual address range in each process to the same physical memory (which can be paged in and out also).
    Oracle database uses this capability (for caches, and control info shared between worker processes), partly because it was developed before threads/tasks became common in Unix, and partly because it allows worker processes to keep some data private for security/robustness reasons.

  3. Richard Danter - Wind River

    Thank you! I really appreciate your feedback!

  4. I recently came across your blog and have been reading along. I thought I would leave my first comment. I don’t know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

Leave a Reply

Your email address will not be published. Required fields are marked *