[cpp-threads] C++ committee meeting in Mont Tremblant

[Hans Boehm]

On Fri, 14 Oct 2005, Peter A. Buhr wrote:

> Otherwise, we have to come up with another mechanism to explain when the thread
> runtime starts and what programmers can assume about the execution model. I'm
> totally opposed to solutions adopting artificial exceptions to the standard
> allocation/deallocation rules, like threads cannot be declared in the global
> scope or threads can only be declared on the heap. These kinds of artificial
> rules are not language design or extension, it is just hacking, and everyone
> will spot it as such.
Isn't this covered by the usual (perhaps implicit?) rule that the standard
library must be usable by the time any user code runs, even in constructors?
We assume that user-defined constructors for static objects must be able to
call ::new to allocate memory, which must thus be (magically?) initialized
first.  Are threads really any different?  Don't you run into problems
primarily because thread primitives are not in the standard library?

I realize that there are problems with initialization order in C++, and I've
been bitten by them.  But I don't immediately see why threads make this any
worse.
>
> This issue is just one example of many high-level issues we should be
> discussing as part of this subcommittee. Concurrency needs a strong memory
> model, but it needs a lot more, so why aren't we actively talking about the
> "other" stuff, too?
>
Certainly, though I think there are some differences in priority.

Hans