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,8bfa8c460ead1701 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Problems with dynamic allocation in tasks Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.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: <1185379864.592973.73220@b79g2000hse.googlegroups.com> <1185383088.872717.223020@l70g2000hse.googlegroups.com> Date: Wed, 25 Jul 2007 20:35:19 +0200 Message-ID: <1jyqrh10qr19l$.1ixdlehwm3tw4.dlg@40tude.net> NNTP-Posting-Date: 25 Jul 2007 20:35:14 CEST NNTP-Posting-Host: 48287c2e.newsspool3.arcor-online.net X-Trace: DXC=6bf=mRnm97_@@RW1FjIB5SMcF=Q^Z^V3X4Fo<]lROoRQ^YC2XCjHcbYW92BLMJek4UDNcfSJ;bb[UIRnRBaCd On Wed, 25 Jul 2007 10:04:48 -0700, ldb wrote: > On Jul 25, 12:45 pm, Robert A Duff > wrote: >> ldb writes: >>>...Ideally, i'd be able to >>> create a task-local memory pool that doesn't require a mutex for these >>> allocations.. not sure how feasible this is in Ada, though. >> >> It's quite feasible. Look up storage pools (section 13.11 in the RM). > > I'm at a loss for how this possible using storage pools. > > I've worked a good deal with storage pools but perhaps my vision of > their functionality is too narrow. It was my belief that a storage > pool can only be used globally for a particular type. In which sense? If you are going to make your pools task-local, then you should know in advance which objects are local to the task. Types of the objects are irrelevant, only access types count. So you just have to use task-local access types. This will warranty that nothing would leak out: task body Foo is Local_Pool : My_Own_Pool; -- The pool of the task type Thing_Ptr is access Thing; -- The access type of for Thing_Ptr'Storage_Pool use Local_Pool; begin ... -- Now each new targeting a Thing_Ptr will go to My_Own_Pool > I -could- make the storage-pool implement a full allocator so it's not > dependant on malloc() for each allocation. This is alot of work and > there are alot of types. You have to implement only Allocate and Deallocate. Choose any of numerous algorithms existing around. You should certainly know about the behavior of your program. For example if you don't need to free objects, then you have an "area", etc. > If I go this route, I'd prefer to do a global > replace (which goes back to my original question of how to do it like > gmem does it). That would be a bad idea, because in that case if you occasionally mixed allocators / deallocators from different tasks, you'd mess up the pool state beyond repair. It would be damn difficult to catch such bugs. With task-local access types you are safe. Note that pool is an object, so you can reuse your pool type implementation across many tasks just creating an instance of for each. P.S. If your objects aren't task-local, you could still avoid mutexes on a single-CPU machine by implementing your pool owned by a protected object with priority ceiling locking (ARM D.3) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de