Re: Elaboration Order

[Robert Dewar <robert_dewar@my-deja.com>]

In article <x7vn1s9ouiu.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> And your compiler (well, binder) may not be able to tell
> whether there is an elaboration problem or not; _you_ may know
> that the task only makes a problematic call after it has been
> allowed to start via some rendezvous, which won't happen until
> the whole program has elaborated, but the _compiler_ may not.
>
> The cases where I've had this problem have both felt a bit
> unsatisfactory when I reviewed the design.

In GNAT, we have recently added the Restrictions pragma

  pragma Restrictions (No_Entry_Calls_In_Elaboration_Code);

This is checked statically by the compiler. It corresponds to
pretty much the normal situation in most programs. It is not
uncommon to have tasks start at elaboration time which
immediately hang on an accept. It is much less usual to start
these tasks off for real during elaboration by making entry
calls.

In the presence of this restrictions pragma (which could almost
be the default, we discussed making it the default in fact, but
decided against it), the compiler knows that such task bodies
do not get beyond the first accept, and thus we can ignore
elaboration issues from calls in subsequent code.

A bit kludgy, but then the whole idea of starting tasks at
elaboration time, which are free to do anything before the
rest of the program is fully elaborated is a nasty one, and
this kind of thing is not easily consistent with static
elaboration.

That being said, if you follow the general design principles
of:

  1. Never start stand alone tasks in elaboration code

  2. Always define separate task types

  3. Put the instances of tasks in separate units from the task
     types.

You can most often get a reliable static elaboration order
without needing this restrictions pragma. The above principles
seem good ones to me in any case, and probably relate to the
"felt a bit unsatisfactory" in above above quote



Sent via Deja.com http://www.deja.com/
Before you buy.