Multi-Thread or Multi-Process?

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.