ANSI/ISO C++ meeting Day 2

OK, it is actually getting somewhat interesting.  Aside from the myriad of straw-polls, and various other procedural items, the technical discussions have some interesting bits.  We're just finished discussing atomics per this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2393.html.  It was actually moderated by one of the authors, Lawrence.

For the Delphi folks on the x86 architecture, it is generally assumed that most memory operations are sequentially consistent without the need for specific memory fences (this is in user-mode where Delphi apps typically live).  However for some other architectures like PowerPC, Itanium and others, explicit memory barriers need to be inserted.  The notion of atomics, codifies this distinction whereby any "normal" variable does not have necessarily acquire/release semantics.  However an atomic variable does have this behavior.  It turns out that the C++ volatile modifier is wholly inadequate for describing the notion of acquire/release.

Another funny item that became a sticking point was whether or not bool (aka. Boolean in Delphi parlance) is bitwise comparable.  Since a bool has one and only one value for "false" (zero[0] typically), yet many bitwise values for "true" (non-zero[0]), you cannot guarantee an atomic "compare and swap" for a bool type.  It is intriguing that such a seemingly simple, fundamental type can present such a problem.

We're now talking about this proposal for a multi-threading library: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html.  Being presented by one of the authors, Howard.   Although the version being presented has had the thread cancellation section removed and explicitly made undefined.  This is because of the notion that cancellation is done via an exception signal... which could be caught and effectively cancel the cancel request...This ended up being rife with other issues (besides the fact that a thread can deny a cancellation request, nay, demand), like intermixing non-C++ frames or even intervening OS frames. 

Discussion of condition variables, which Windows doesn't have any intrinsic primitive (not until Windows Vista), has been somewhat interesting (and another sticky point).  Pete Becker (former Borland C++ RTL guru)  has raised the issue that the current proposal seems to be designed with a bias to POSIX (through BOOST) and unnecessarily complicates the implementation of condition variables for systems that don't have a native conditional-variable-like thingy.  In looking at potential implementations for a condition variable on Windows in the absence of native condition variables, it becomes abundantly clear that this isn't an easy problem to solve.  Geez.. the machinations that these various algorithms go through is astounding.  However, a condition variable construct makes implementing things like thread-safe message queues and stacks where the producer want to know "not full" state and the consumer is interested in the "not empty" state.

 

Afternoon session:

OK, we just spent over an hour wrestling with the notion of whether or not a reference is also a memory location (as defined by this document: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.htm).  Even though you cannot take the address of a C++ reference, it may in fact occupy a memory location.  So given that, should it share the same semantics as a regular memory location?  It all sounded so metaphysical for such an analytical group.  I understand the arguments on both sides, however the one argument I could not disagree with is that unless you call it out, some "clever" compiler writer may decide to do something "special" with references regardless of whether or not they live as a memory location or not (references can be collapsed by optimization).  Finally past that... now we're trying to define what a "thread" is...  Pretty soon my head is going to explode :-).  blah blah blah...

 

I think that is it for day two... we'll see if I have the gumption to say anything about day 3 :-)