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/25 Message-ID: #1/1 X-Deja-AN: 198613154 references: <325BC3B3.41C6@hso.link.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-11-25T00:00:00+00:00 List-Id: In article , Kevin D. Heatwole wrote: >Is it really that much harder to provide an efficient ref-counted tasking safe >implementation of unbounded strings than it is to provide an efficient tasking >safe allocator? Two points: You can make "new" efficient by having per-task pools of memory. Allocate each task 4K (say) and use that for "new". And if it runs out, allocate some more from a global pool. Or steal some from another task. This will reduce the probability of lock contention. I suspect that the most efficient method for unbounded strings is to use full-fledged garbage collection. I don't KNOW that, but from reading various papers by GC advocates, I suspect it's probably true. And I'm talking about non-real-time systems here, where we care about best "typical" performance -- I don't think one uses unbounded strings in hard-real-time situations. Of course, it's hard to implement an efficient GC -- doubly so in a multi-threaded language. OK, here's a third point: All this talk about inefficient locks is based on the assumption that each Ada task is mapped to a single OS thread. If you're willing to give up the benefits of that (on, say, Windows 95), then it's not hard to do very efficient locking. - Bob