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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news.addix.net!feed.news.schlund.de!schlund.de!rz.uni-karlsruhe.de!news.belwue.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> Date: Tue, 8 Mar 2005 21:59:33 +0100 Message-ID: <157t6st03yru3.124h9wuwhw9si$.dlg@40tude.net> NNTP-Posting-Date: 08 Mar 2005 21:59:31 MET NNTP-Posting-Host: 7ed4b2c2.newsread4.arcor-online.net X-Trace: DXC=n\[fH\BVDXm0_l3b[L=KQc:ejgIfPPlddjW\KbG]kaMhGSi?jHD8GO`NK0oFROO;ki[6LHn;2LCVnCOgUkn_?_YoD\WW9GEV\Gf X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8885 comp.lang.c++:44657 comp.realtime:1084 comp.software-eng:4640 Date: 2005-03-08T21:59:31+01:00 List-Id: On Tue, 08 Mar 2005 15:13:20 -0500, CTips wrote: > Dmitry A. Kazakov wrote: > >> On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote: >> >>>How easy is it to build an arena allocator in Ada? >> >> It is trivial: >> >> type Object is ...; >> type Object_Ptr is access Object; >> for Object_Ptr'Storage_Pool use My_Arena; >> >> Here you are: >> >> Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena > > And how is My_Arena defined? Is it just a blob of memory? Or is it a > "class" that can invoke sbrk (or whatever) when it needs to? It is completely up to you. My_Arena has to be derived from System.Storage_Pools.Root_Storage_Pool. Which is the abstract base of all storage pools. The implementation of Allocate and Deallocate is at your discretion. For an arena the pool may contain a statically allocated array organized as a stack. Deallocate could be then void, or it can pop everything above it as in mark'n'release. A more advanced application could allocate memory in segments at request etc. For a sample implementation of a segmented stack pool see: http://www.dmitry-kazakov.de/ada/components.htm#Pools_etc >>>Given a processor with load-word-locked and store-word-conditional, how >>>would I build an atomic increment function? >> >> Why should I have atomic increment function? Ada has native concurrency >> support. But if somebody would need that extremely low level thing as >> atomic integers, then: >> >> protected type Atomic_Integer is >> procedure Increment; >> private >> Value : Integer; >> end Atomic_Integer; >> >> -- Implementation >> protected body Atomic_Integer is >> procedure Increment is >> begin >> Value := Value + 1; >> end Increment; >> end Atomic_Integer; >> > Will that generate: > L0: > lwlock temp,&Value > add temp,temp,1 > stwcond temp,&Value > if( failed ) goto L0; > or will it generate something much more heavy-weight. Ask your compiler vendor. Though it wouldn't be necessarily polling. Also usually protected objects are not used for so utterly fine-grained mutual exclusion/locking. Atomic integer increment is normally just a small part of some larger (but not lengthy) operation. For example, placing something in a queue. Therefore spinning for a lock (which probably would be the implementation) will likely be less expensive than some tricky guards attached to each and every instruction. Note also that at such a low level it would be very difficult if possible to maintain data consistency. Compiler simply does not know what is related to what and will try to cope with the worst case scenario. Protected types in Ada are to describe this sort of semantics. So in the end atomic integers are pretty useless, no matter how efficient they could be implemented. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de