The C++ standardization committee is hard at work standardizing threads for the next version of C++. Some members recently met to discuss the issues, and The C++ Source was there. Read on to learn what the world’s leading experts on concurrency are planning for C++0x.

http://www.artima.com/cppsource/threads_meeting.html

What is your opinion about the threading standardization issues discussed in this article?

I really do not understand their complicated way of thinking. Why don't they simply specify a simple library with the following classes:

-thread
-critical_section
-mutex
-semaphore
-wait_condition
-lock< T> (for RAII)

That's all that is needed.

The rest of considerations (for example, order of optimizations etc), while not irrelevant, are very excuisite. For example, whoever wants to have atomic bitfield manipulation can always use a critical section to lock a data structure.

Furthermore, there is no need to extend the language with new keywords.

Finally, it seems really strange that they are going to put threads in the language but no garbage collection. We can live without threads (all it takes is a few lines of code to wrap the native primitives into C++ classes) but it is really difficult to write a collector without compiler support.

Thanks for the article! While the C++ standardization committee truly believes their work is open, in practice very little ever gets to the rest of us.

One thing I don't understand is the reluctance for introducing new keywords to the language. Frankly, i like Lawrence Crowl's proposal best - not because of compatibility with C, but because it is clean and simple. Are new keywords hard for compiler vendors?

Achilleas,

Please Google "Boehm "Threads Cannot Be Implemented As A Library"". In that paper, Hans describes in detail why we can't just standardize thread and lock classes and call it good. For those classes to actually work across platforms, they need to be able to rely on things that the language currently doesn't guarantee. Standardizing C++'s memory model is the first and most important step towards standardizing threads in C++.

--
Eric Niebler

Nemanja.

One of the big reasons why the committee avoids adding new keywords is the fact that it can potentially break source code. Imagine the chaos that would ensue if "fork" were taken to be a keyword. Every program that uses the identifier "fork" would stop compiling. So we couldn't use "fork", we might have to use "__fork" or "_Fork" something ugly like that.

Sometimes you can't get by without a new keyword, and several new ones ("static_assert", "concept") are proposed for C++0x. But when a viable library solution exists, it's a safer bet.

--
Eric Niebler

> Imagine the chaos that would ensue if "fork" were
> taken to be a keyword. Every program that uses the
> identifier "fork" would stop compiling.

Eric, Thanks for answering.

It may be just my ignorance, but it should be possible to add context-sensitive keywords, like in C++/CLI: http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx

Therefore, fork would be a keyword only within a certain context, like (form your article):

int join pending = fork work1( argument );

Am I missing something? Again, I my knowledge of compiler internals is all but non-existing and I appologize if I am suggesting something utterly stupid.

Also, I appologize for the horrible spelling. This forum doesn't seem to have an "Edit" option.

This first thing I thought of when reading about this was "Why do they want to turn C++ into Java?"

It doesn't seem to me that language-based threading has been effective enough in any language to recommend it to C++.

Rather than trying to paper-over the differences between OS threading models with a one-size-fits-all model, C++ programs address threading at the OS level and end up with more efficient threading without the leaky abstraction surprises that are common with threads-as-objects schemes.

> This first thing I thought of when reading about this was
> "Why do they want to turn C++ into Java?"
Possibly because threading works very well in Java (in my opinion).

> OS threading models with a one-size-fits-all model, C++
> programs address threading at the OS level and end up with
> more efficient threading without the leaky abstraction

Java threading can be more efficient than you can easily achieve in C++. For example the implementation of the synchronization primitives depends on how many CPUs are present at RUN TIME. The performance is much better than straight forward use of the Windows critical section methods.

> Java threading can be more efficient than you can easily
> achieve in C++. For example the implementation of the
> synchronization primitives depends on how many CPUs are
> present at RUN TIME. The performance is much better than
> straight forward use of the Windows critical section
> methods.

The Windows critical section is the most limited of its synchronization primitives in that it is only useful within a single process. The other primitives are kernel objects and work just fine with multiple CPUs. I don't know enough about Windows internals to know what kind of optimization they do, but I would certainly be skeptical of the idea that Java does it more efficiently. Any measurements to back that up?

The main problem with Java is that the threading behavior of a program isn't necessarily consistent across OS's.

Nobody is trying to "turn C++ into Java." The committee is interested in standardizing existing practice. We should standardize threads for the simple reason that lots of people are writing multi-threaded C++ programs today. To not put threads in the standard would be to ingore the needs of real C++ programmers.

--
Eric Niebler

Nemanja,

It's not a dumb question at all to wonder if the keywords Lawrence suggested can be made context sensitive. I don't honestly know the answer, although the fact that the "fork" and "join" could show up an arbitrary expressions leads me to think it would be difficult if not impossible.

But here's something else to think about. Microsoft added context-sensitive keywords to their language, because they only had to add them to one compiler: theirs. The committee would have to consider all compilers out there when evaluating the feasibily of adding such a feature.

--
Eric Niebler

> Nobody is trying to "turn C++ into Java." The committee is
> interested in standardizing existing practice. We should
> standardize threads for the simple reason that lots of
> people are writing multi-threaded C++ programs today. To
> not put threads in the standard would be to ingore the
> needs of real C++ programmers.

Standardizing existing practice is fine. The problem is that existing practice is platform-specific due to the significant differences between OS implementations of threading.

> Standardizing existing practice is fine. The problem
> is that existing practice is platform-specific due to
> the significant differences between OS implementations
> of threading.

And that's exactly why we need a standard -- so that nobody has to write platform-specific code if they don't want to.

This goes beyond a particular OS's implementation of threading, and right down to the hardware. Consider that an OS like Linux which runs on multiple platforms must "paper over" the hardware differences in order to present a coherent threading API. This is handled by a hardware abstraction layer. We're essentially doing the same thing, except that "papering over" actually consists of finding the core primitive operations supported by all modern computer hardware -- operations like atomic memory access, barriers and fences. Taken together, they define an abstract machine (not to be confused with a VM in the Java sense). Now, we define the semantics of C++ in terms of this abstract machine, and we have a sound basis on which to build multi-threaded C++ applications that are efficient and cross-platform.

--
Eric Niebler

> This goes beyond a particular OS's implementation of
> threading, and right down to the hardware.

Perhaps I missing something, but wouldn't implementing threading at the hardware level rather than through the OS have the potential to bring the OS crashing down? How can two entities be manipulating the same hardware registers to different ends?