Ambassador

Lock-free, continued
I have realized that my previous post sounds a bit scientific, now I will try to sum up and bind result to C++.

We have got couple of works, scientific works, upon lock-free containers and data structures, some of them are already patented. These are, however, still too complicated and very limited.

Hardware support
Today, Intel i386 family processors facilitates some atomic operations in three ways. My understanding:

• Prefixing instructions with LOCK may not assert a LOCK# signal on bus, but locks cache on the CPU, if requested area is already in the cache.
  
• CPUs guarantee cache coherence through a special protocol (only on P6)
  
• CPU asserts LOCK# signal on bus, modifies memory.
  

(By the way, I have studied electronics engineering, not computer science)

Bottom line is that we need hardware support to perform lock-free operations correct and quick, and atomic operations are still costly today.

C++ standard, of course, does not mention lock-free techniques. I happen to believe it will not mention it in upcoming standards, too. Because the subject is not in language's scope, in my opinion.

Back to threads
Thread synchronization, as very briefly discussed here, is part of our lives if we have to modify shared data in a multi-threaded environment.

Most Win32 programmers already know there are couple of C++ classes on the web, wrapping handles and providing C++-ish ways to deal with threads and synchronization objects. I am not developing multi-threaded applications on UNIX so I don't know existing libraries but as far as I have heard, there are really cool libraries for UNIX as well.

Software people at Intel was working on a library, I couldn't find the library's URL, but there was a discussion on comp.lang.c++.moderated.

Managed run-time environments, or virtual machines, like JVM (Java Virtual Machine) and .NET CLR have sort of "thread object", which boils down to a wrapper (component) over a native thread. I am not a Java expert, and I have heard that not all threads in JVM are native threads - I don't know how true it is, it sounds like fibers scheduled by VM. In fact, everything in Java has to be encapsulated by an object, anyway.

C++ and concurrency
For a couple of years, C++ people discussed language support for concurrency. Herb thinks "concurrency will be the next revolution in software engineering, much like object oriented programming did". C++, as a mainstream language, would like to, not just catching this train but, being a part of the locomotive that brings us to concurrency world. It's not just about wrapper thread classes this time, but proper compiler support, real thread objects, asynchronous functions, lock-free containers, Open MP support (well, not quite sure) and similar stuff are considered to be in upcoming C++ standards.

It's not impossible, but quite difficult to write correct (or reasonably correct) threading libraries today. What we will, hopefully, have are an International standard and compliant compilers that facilitate moving multi-threaded applications to mainstream. In last year's PDC, Herb has given a talk about some concurrency additions to C++.

Garbage Collection
Some mainstream languages and (virtual) platforms today utilize an old invention, called "garbage collection". C++, from standard's point of view, did not have it. There are just a couple of third party libraries working pretty good.

Garbage collection technology is fairly difficult to implement and some C++ people have some concerns; "does GC degrade performance of my C++ application?" "what if I want to do extreme programming and GC restricts my moves?" and a few more, probably arose because of garbage collection implementations they see in the market.

GC is, in its nature, essentially designed for performance concerns. But it introduces some essential problems as well. Today's mainstream managed run-time environments (.NET and JVM) sometimes suffer their compacting garbage collection designs. First problem is that they do not have a deterministic destruction but a non-deterministic finalization. Every application running on VM has at least 2 threads; one for process' main thread and one for finalizer.

How did C++ come today without garbage collection? We've had idioms and patterns, such as smart pointers (e.g. std::auto_ptr, boost::weak_ptr, etc) and reference counting (e.g. COM's IUnknown). These tools and techniques facilitate managing memory.

Compacting GC may improve performance, in particular in long-running applications, because it causes less or even fixes memory fragmentation problems.

First of all, one should not take Java and .NET as "the only GC implementations" around, but should look a bit wider vision. A GC implementation may not collect all objects, but may take it one step further and distinguish "GC types" and "non-GC types" (e.g. "this type of objects are managed by GC"). Non-deterministic finalization is not necessary. As Herb pointed out and implemented in C++/CLI as well is "delete first, collect later".

SomeGCType^ h = new SomeGCType;
// ...
delete h;  // call destructor, reclaim memory later.

In other words: "call destructor deterministically and I don't care when you collect the memory". That is quite suitable for all C++ programmers.

One common misconception is that "GC manages all resources". RAII pattern is widely used in C++ and every C++ programmer knows how and when resources they have acquired will be closed/freed. For a Java or a .NET programmer, well, they don't know/care what is (deterministic) resource management. Finalizers have one "feature"; a finalizer can run 0 or more times and they do weird things in finalizers. Nonetheless, a GC'ed C++, which has features implemented in C++/CLI today (I have mentioned above; distinct types, deterministic destruction), works very cool.

There are some discussions and concerns about garbage collection, but it seems like we will have garbage collection in upcoming C++ standard(s). ISO C++ will most probably have a GC close to C++/CLI design rationale.