Introduction

Parallel processing is in modern computers a given. More and more you have hardware support for parallel processing, like Hyperthreading, multiple cores or multiple CPUs. But even without real parallel hardware support, modern operating systems give you a quasi-parallel execution environment even in pretty small embedded systems.

Given that reality, there is probably a general agreement in the C++ standardization committee that C++0x needs to address parallel processing. Where there is no general agreement yet is how such support should look like.

This paper argues that fixing the execution model for C++ is a must, while having a low-level "threading" or "locking" library might be a bad idea.

Threads vs. Parallel Processing

A general note on terminology and concepts: some papers and authors use the term multi-threading when addressing parallel processing, and some use parallel processing when addressing multi-threading.

This paper uses the term thread for a separate thread of control in completely the same address space (without the possible exception of specifically declared thread-local storage). This was common practice in operating systems like PC-DOS where all tasks shared the same address space.

This paper uses the term parallel processing generally for separate thread of controls. In modern operating systems this often provides different address spaces, but allow sharing some common resources (memory and others).

A lot of current literature proposes threads as a solution for parallel processing needs, but this is almost always a bad idea. Any standard C++ feature that promotes threads instead of general parallel processing means would be a bad service to the C++ community.

Core Level Support

Paper N1777 and Andrei Alexandrecu's presentation in Redmond and Hans Boehm's presentation in Lillehammer showed clearly that the current execution model of C++ is underspecified for parallel executing tasks accessing the same memory.

Some (including the author) believe that in that context the keyword volatile should play a role to mark memory that is accessed from different tasks in parallel. But if volatile gets some useful meaning (whatever), there are several parts of the C++ standard that need some revisiting (e.g. does an implementation provide a volatile op=, do standard library classes (like complex<>) support volatile operations, etc.).

Library Support

Fixing the execution model of C++ helps for those using implementation specific functionality. But without some standard library support there is no way for a C++ user to use parallel processing in a standard way. While paper N1815 simply states "The standard must define some mechanism for locking.", this paper proposes a different approach.

For standard library extensions for parallel processing support exist different ideas. These can be categorized into different domains:

• high-level classes for shared resources and asynchronously executed procedures

• low-level synchronization classes

• thread starting and control

Conclusion

All support for parallel processing in C++0x must work for processes. Support for threads might also be useful, but has lower priority.

C++0x must provide an execution model that generally supports asynchronous access to objects.

If library support for parallel processing is provided, a high-level library has absolute priority.

A low-level library that is really useful requires a major effort and is therefore probably out of scope for C++0x. A half-baked low-level library would be a bad service to the C++ community. A half-baked low-level library without a high-level library would be disastrous, as this would give the message "Use this dangerous library, because it is standard, instead of a safer non-standard library."

Generally, a C++ library approach along the lines of POSIX threads is very problematic, as that specification is focused on low-level support, while an approach along the lines of OpenMP looks much more promising, as that specification focuses on high-level constructs while still providing some low-level functionality.

Just as a side note: we currently have a similar situation with the C++ I/O streams library. This supports generally safe and easy to use high-level abstractions instead of the low-level OS-specific functionality like memory-mapped files and asynchronous I/O that is often required for system programming.