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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: bobduff@world.std.com (Robert A Duff) Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Date: 1996/11/29 Message-ID: #1/1 X-Deja-AN: 201309327 references: <325BC3B3.41C6@hso.link.com> <329C945E.6FCB@watson.ibm.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-11-29T00:00:00+00:00 List-Id: In article <329C945E.6FCB@watson.ibm.com>, Norman H. Cohen wrote: >That doesn't seem like a good idea. I didn't mean it's *always* a good idea -- it depends on the program. >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). Yes, but there are a lot of programs that use fixed sizes, or a small number of fixed sizes. >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. Yes, if you always go to the global heap when you run out. An alternative is to steal memory from another task. This means that you have to lock the per-task heaps, but the scheme can still win, because getting a lock that's not already locked can be made cheap, and the scheme reduces that probability in many cases (though not in the case you mention above). - Bob