ANSI/ISO C++ meeting Day 3

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html - Went over this paper some more and rehashed the issue surrounding whether or not the thread object should detach or join the underlying OS thread.  Join and detach are POSIX thread notions and roughly correspond to Windows WaitForSingleObject(<thread handle>) and CloseHandle(<thread handle>).  Looks like their going with the detach rather than the join, mainly because they had no known prior art where a thread object does a join in the destructor.  Alisdair, at my prompting, did make it known that the Delphi TThread object does, in fact, do a join in the destructor.  So.. there's my contribution to the C++ standards process... they're still going with the detach, but it was a long, long discussion.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html - This paper was just covered in the final session of the day.  What is interesting is how they define thread-safety guarantee.  There is the notion of basic thread-safety and strong thread-safety.  Adding "strong" thread safety in which a globally shared object can be mutated by more than one thread in a safe manner has a significant negative impact on performance.  There are so many notions of "thread-safety" that it is so hard to nail down one... some are small in scope where they're only dealing with atomic operations on single "memory-locations" and then the much broader notion that many folks seem to relate with is the strong notion.  The problem is that this "strong" notion is not actually the case where "I can write my program in any way I see fit without regard to how the threads interact."  Even all the work going on to leverage multi-core systems both in the libraries and even intrinsically by the compiler, these are not "strongly" thread-safe in the broad naive notion.

Now they're talking about random number generators...  Cool.. I needed a nap :-).