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

[jimmaureenrogers at att.net]

 -------------- Original message ----------------------
From: Hans Boehm <Hans.Boehm at hp.com>
> 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

The following extremely simple Ada example may demonstrate the
issue.

Procedure Set_Up runs in the main task. There is no active part
of Set_Up. Its execution is simply a null statement.

The declarative region of Set_Up declares and defines a single
task named Busy. Busy simply outputs the numbers 1 through 10
on stdout, one value per line.

Ada provides an elaboration phase before the normal execution
phase. The task Busy is created and started implicitly during
the elaboration of Set_Up. The execution phase of Set_Up is
effectively bypassed by the null statement.

with Ada.Text_Io; use Ada.Text_Io;

procedure Set_Up is
   task Busy;
   task body Busy is
   begin
      for I in 1..10 loop
         Put_Line(Integer'Image(I));
      end loop;
   end Busy;
begin
   null;
end Set_Up;


This example may slightly differ from the concept of
global creation of threads since Ada does not provide
any way to create globals. The issue of execution order
is still valid. The Ada example creates two tasks. 
The main task creates the Busy task before the main
procedure begins execution.

The Ada execution model clearly explains the behavior
of this program. There is also no requirement to create tasks
using dynamic memory allocation. This task is created on
the stack.

--
Jim Rogers
Colorado Springs, Colorado
U.S.A.