This document describes a few common error patterns to help you identify and correct some of the problems you may have in writing SMP-safe code.
unsafe assumptions about thread execution order
unsafe assumptions about memory/data sharing.
Most of the errors found in code so far are not unique to SMP, but are more likely to be found on an SMP system. Some existing code makes assumptions about how threads are scheduled and how thread priority affects the sequence of operations across multiple threads.
For example, one thread makes a request on a server. The developer assumes that the server will complete the request before the calling thread became active again. This is a dangerous assumption as the server might not be ready to run, or could pause while waiting for a resource. This would mean that the scheduler could continue executing the original calling thread before the server has completed the request.
The above example would be even more likely to be an unsafe assumption on an SMP system because the scheduler could run the server on one CPU core and the original calling thread on another at the same time. This is why it is important for the calling thread to be written in a thread-safe manner which waits for the server to complete the request before continuing into code that requires that request to be complete.
Common Error Patterns - Execution Order describes a number of common error patterns that have been found during SMP testing.
Common Error Patterns - Case Studies provides specific examples of common error patterns.
Errors may occur if multiple threads try to update or delete the same memory areas at the same time.
Good programming practice, whether for single core or multiple core, is to lock objects while they are being updated to prevent them being read by another thread in the middle of an update. For kernel-side code use a lock to ensure that a particular thread has exclusive access to data and interrupts.
One problem that has been found, though not specifically SMP related, is where the flexible memory model is being used. For global chunks, memory locations are accessed as an offset to a base address. However, each thread may have a different base address for the global chunk: if applications use absolute addresses, they will read the wrong data.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.