Re: Self-referential types

["Robert I. Eachus" <eachus@mitre.org>]

Robert Dewar wrote:
  
> Ah ha! There it is. The trouble is that the creator may not
> think tasking is an issue, but later on a consumer is interested
> in task safety. PLEASE PLEASE default your thinking to assume
> that tasking *is* an issue, and make thinks task safe by
> default. Only introduce (well documented!) thread non-safety
> deliberately if there is a VERY good reason for it.

    Sorry, that was an aside that could be misleading.  I was referring
to a different issue:  The cases where the outer  procedure creates one
or more tasks.  These cases are somewhat harder to deal with because of
the rules about masters and when a scope is left.  For instance if you
move a task out of a procedure, so its entries are visible to other
(formerly nested) procedures, then you may have to add explicit code to
terminate the tasks at the right point in time.  This is why you may
want to instantiate a generic package inside the procedure to get the
right semantics without kludges.

    In the cases Robert Dewar is talking about, where tasking is not
dealt with in otherwise sharable code, you can often factor the tasking
out at a higher level.  I often wrap procedures this way:

  procedure Protected_Foo is begin Lock.Seize ; Foo; Lock.Release; end;
  -- add parmeters to taste.

  This provides both tasking and non-tasking safe versions.  It will
work correctly even if Foo is recursive.  The other way to deal with
potential tasking is to pass all shared data in one or more explicit
parameters.  This way the caller can do anything necessary at his
level.  The random number packages in Ada are a result of this type of
thinking.  Since they pass a generator object around, it is up to the
user in a tasking environment to decide which tasks should share
generators and how.


-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...