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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b84f51b862b7b6f5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-10 03:35:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn14feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!central.cox.net!cox.net!nntp2.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!nntp.clear.net.nz!news.clear.net.nz.POSTED!not-for-mail NNTP-Posting-Date: Fri, 10 Jan 2003 05:35:37 -0600 From: Craig Carey Newsgroups: comp.lang.ada Subject: Re: String library with garbage collection? Date: Sat, 11 Jan 2003 00:35:20 +1300 Message-ID: References: <501s1voa23mlkfu93dailpb04dh20u7b0n@4ax.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Customer of Mercury Telecommunications Ltd Cache-Post-Path: drone5.qsi.net.nz!unknown@tnt1-113.quicksilver.net.nz X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Original-NNTP-Posting-Host: drone5-svc-skyt.qsi.net.nz X-Original-Trace: 11 Jan 2003 00:35:25 +1300, drone5-svc-skyt.qsi.net.nz NNTP-Posting-Host: 203.97.37.6 X-Trace: sv3-bPuILD+fWsqgWw4EuJu+R2KIEnn9ifPY6dDag/hBUcDMZB5KNGnwVutwkLKfQ8hLUy22y8xJzxyKvOo!TzbicplL5IjiEoBc4I3Wrw+V3/IJ40HMqSl4UyVUzjMDsX2+MGukyqIxas7yo5XmxkVXs+XlBJpl!HFEX5C4= X-Complaints-To: Complaints to abuse@clear.net.nz X-DMCA-Complaints-To: Complaints to abuse@clear.net.nz X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:32876 Date: 2003-01-11T00:35:20+13:00 List-Id: On Fri, 10 Jan 2003 03:52:13 GMT, "James S. Rogers" wrote: >"Craig Carey" wrote: >> On Thu, 09 Jan 2003 20:46:45 GMT, "James S. Rogers" wrote: ... >It is true that global constants are safe to access. > E.g. constant pointers in linked list of nodes where each node is labelled with a Task_Id. Task can simultaneously traverse it safely. To add a new node, some safer scheme is used. If tasks correctly identify their own node and only write to that, then parallel update also does not need to be protected. Checks to see which nodes are no longer used, also do not need to be protected. An idea is that the function to find the Task_Id, "Ada.Task_Identification.Current_Task ()", is faster than protected objects (and that is true of the GNAT 3.15_ implementation): RM C.7.1 The Package Task_Identification http://www.adaic.org/standards/95aarm/html/AA-C-7-1.html >Furthermore, pragma Atomic() is really only useful on a uniprocessor system. I notice the correction. >There is no way to check Task_Id's and update or read a linked list >element atomically. This entails at least two reads, or a read and a write. Those words "is no way" seems to be inconsistent with these words: "global constants [that] are safe to access". ... >> RM 9.10 defines "erroneous": >> http://www.adaic.org/standards/95aarm/html/AA-9-10.html > >Read that definition again. "Erroneous" execution is not a desired >behavior. That would be rejected using this argument. RM 9.10, does not actually have extra words to differentiate between the "updating" of, and the "reading" of, the "global constants" (may need to add the constraint that the variables be genuinely 'volatile' (updates are actually done before the next read). RM9.10(11) uses the word "or" to have the same constraints on both the idea of reading and writing ("updating"), be applied in an atomic action: "Given an action of assigning to an object, and an action of reading or updating a part of the same object ... is erroneous unless ...". I thought Mr Rogers was trying to nail down this group as holding a desire of preferring to avoid owning erroneous programs. To keep the thread shorter, some corrective statement is appropriate. [I didn't see text in the RM saying that Task_Id's should be uniquely assigned over the life of the program.] PS. Correction: 0x2000 bytes = 8192 bytes Craig Carey Some Ada 95 mailing lists: http://www.ijs.co.nz/ada_95.htm