Re: Global Varibles!!

["Norman H. Cohen" <ncohen@watson.ibm.com>]

Robert Dewar wrote:
> 
> Norman said
> 
> << package Serial_Numbers is
>    procedure Get_Next (Number: out Natural);
> end Serial_Numbers;
> 
> package body Serial_Numbers is
>    Next: Natural := 0:
>    procedure Get_Next (Number: out Natural) is
>    begin
>       Number := Next;
>       if Number = Natural'Last then
>          Number := 0;
>       else
>          Number := Number + 1;
>       end if;
>    end Get_Next;
> end Serial_Numbers;
> >>

Oops!  What I meant to write, of course, is:

   if Next = Natural'Last then
      Next := 0;
   else
      Next := Next + 1;
   end if;

> Of course in general this kind of hiding is quite appropriate. Note however
> a danger, here we have an unexposed global variable that is not protected
> against task switches. If the global is in the spec, you are at least
> clearly publishing a warning that you have an unprotected global.

Robert correctly points out that this version of Serial_Numbers is not
task-safe.  If the intent is that the package be task-safe, it can be
made so in any of a number of ways (at the cost of performance and/or
simplicity of the interface), including:

1. using a protected object in the package body

2. replacing Next by a per-task attribute (see "The Package
Task_Attributes", RM C.7.2)

3. replacing the global variable with a parameter carrying private
per-task state, which might be considered overkill in the Serial_Numbers
case, but is essentially the role that type Generator plays in the
predefined random-numbers packages (RM A.5.2).

If the intent is that the package not be task-safe, this should indeed
be documented, but I would prefer to do this with a comment rather then
by exposing the global variable in the package spec.  

Alternatively, if approach #1 is used to make the package task safe,
this could be documented by declaring the protected object in the
package spec rather than declaring a procedure in the spec, declaring
the protected object in the body, and implementing the visible procedure
with a call on a corresponding protected procedure.

This gives rise to the following question:  In the absence of any
documentation to the contrary, should a package be assumed to be
task-safe or task-unsafe?  A purist view is that all packages should be
assumed by default to be task-safe, and that the author of a task-unsafe
package should document the fact that the package is not task-safe.  In
reality, many programmers implicitly regard a single-task program as the
"normal" case and a multitask program as an exotic special case.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen