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,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: "Norman H. Cohen" Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Date: 1996/11/27 Message-ID: <329C945E.6FCB@watson.ibm.com>#1/1 X-Deja-AN: 201098902 references: <325BC3B3.41C6@hso.link.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: 1996-11-27T00:00:00+00:00 List-Id: Robert A Duff wrote: > In article , > Kevin D. Heatwole wrote: > >I suspect that even this approach would have some difficulties involving > >pool-specific (or global) locks. While task A may allocate the storage > >out of its per-task pool of memory, task B may be the task that deallocates > >the memory later. If you have two threads mucking about with the same > >pool of memory, you will need to implement some form of serialization. > > If you implement your pools with free lists, then when you deallocate, > you can put that chunk of memory back on the current tasks free list, > despite the fact that it was allocated from some other task's free list. That doesn't seem like a good idea. Apparently you're assuming fixed-size allocations, so that there is never a need to coalesce a freed block with neighboring free storage (or else you are deferring the coalescing until the next allocation by the task owning the free list). More seriously, however, imagine a producer/consumer design in which the producer task allocates and initializes an object and passes the access value pointing to it to the consumer task. The consumer task processes the object and deallocates it. In your scheme, the producer task will constantly be requesting more and more storage blocks from the global heap so that it can chop the blocks up into allocated objects; all of the allocated objects eventually end up on the consumer task's free list, but are never used again. -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen