ANSI/ISO C++ meeting Day 4

Shameless namedrop... sitting across the table from Herb Sutter(from MS) and Bjarne Stroustrup (from AT&T labs) in the Evolution/Concurrency Working group discussing http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2407.html.  Just to make it clear to the Delphi and C++Builder folks... we've had this for many years in the form of packages.  It's good that the standards bodies are getting on board with this concept.  Of course there are many issues with defining a standard that can be implementable among various platforms, mainly Unix (and similar) and Windows...  Well it looks like this proposal has died in committee due to the fact that many felt that they would be unable to finalize the proposal in time to get a new standard out by 2009 (aka. C++09, from C++ox).

Next discussion is more informal and is related to garbage collection... should be interesting.  Apparently there will be a minimal specification of garbage collection in the next standard (at least at this point).  Main sticking points are about obscured pointers, leak detection, and destructors.  No, no... GC, as defined in the original proposal, is not in. Geez, it is hard to track all the different proposals and their status as they wind their way through the various subgroups.  Looks like they've decided to put in some special library functions to allow certain annotations to give "hints" to any collector about whether or not a memory region contains or doesn't contain reachable pointers.

Great googly-moogly, now the discussion is about the definition of "may"...  now they're discussing that "need not" is the negative form of "may."  Stop before I go insane :-).

Now in the afternoon session where they're finally trying to nail down the final proposal for the threading library.  Working on some interesting problems with the try_lock() function.  It seems that there are cases where try_lock can return false even if the lock is available.  The details are somewhat abstract and platform specific.  In properly written code, a "spurious failure" of try_lock() is not really a problem.  The one degenerate case as presented by Hans Boehm (from HP) (translated to Delphi code):

var   x: Integer;   M: TMutex;
thread #1	thread #2
x := 1; M.Lock;	while (M.TryLock) do   M.Unlock; Assert(x = 1);

It was quickly pointed out that this is considered "bad" programming practice.  The issue is that there is actually a race because if try_lock() fails (and failure in this case is the notion of not acquiring the lock even though it is available).  On multi-processor/core systems with guaranteed cache coherency, it is hard to see a case where a "compare and swap" (the typical underlying mechanism for implementing a mutex) operation would fail spuriously.  I do agree that with properly written code (NOT the code above :-)), this should not be a problem.