From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8d182ecfa9220b7d X-Google-Attributes: gid103376,public From: "Norman H. Cohen" Subject: Re: Global Varibles!! Date: 1997/02/25 Message-ID: <3313153F.15CB@watson.ibm.com>#1/1 X-Deja-AN: 221380775 References: <330B6914.22CD@hotmail.com> <330DD315.6562@watson.ibm.com> Content-Type: text/plain; charset=us-ascii Organization: IBM Thomas J. Watson Research Center Mime-Version: 1.0 Reply-To: ncohen@watson.ibm.com Newsgroups: comp.lang.ada X-Mailer: Mozilla 3.0 (Win95; I) Date: 1997-02-25T00:00:00+00:00 List-Id: 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