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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Wed, 9 May 2018 00:43:58 +0300 Organization: Tidorum Ltd Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com> <87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com> <87efiuope8.fsf@nightsong.com> <87lgd1heva.fsf@nightsong.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net aISh6P1s5VxmRbbNF+9HUQBqx1yrlzxzWZrKLOfNWmnGJuhuj/ Cancel-Lock: sha1:VPXiDu6WUkaIve4hqgzzyDgUtOI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87h8njmk4r.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52136 Date: 2018-05-09T00:43:58+03:00 List-Id: On 18-05-07 20:49 , Paul Rubin wrote: > "Dmitry A. Kazakov" writes: >> The difference to GC is determinism and efficiency. You don't need to >> lock in order to decide if the object must be reclaimed. > > I don't see it. I saw the word "lock" and thought you meant a > concurrency lock, but I think you mean the notorious GC pause. Yes that > was a noticible issue in the 1980s but it's much less of one now. In > any case, something similar happens with refcounting: if you drop the > last reference to a large structure, you have to recursively traverse > the structure to decrement the refcount of everything that the structure > contains pointers to. So you still get arbitrarily long pauses. True in general, but in the kinds of applications that I work on, and I believe in Dmitry's applications too, the length of such nested pointer chains is small and bounded. In fact, in all my current uses of reference counting, there are no nested pointers in any reference-counted object, so no recursive ref-count decrementation. For the general case, I remember seeing some papers where the recursive reference-count decrementation was amortized over time, by recursing only by a bounded amount, and leaving (enqueuing) the rest of the job for later. This is similar to the GC systems where collection pauses are bounded. > Regarding concurrency: any concurrent system is non-deterministic by > definition. So handling non-determinisism is simply part of the deal > when you find yourself writing a concurrent program. When one writes a concurrent program, the aim is to ensure that the program behaves as deterministically as required, even though the inputs are non-deterministic in content or timing. For example, schedulability analysis is one tool for ensuring a deterministic result (deadlines are met) in the face of non-deterministic inputs (variable input timings and task triggerings). Additional non-determinism from the run-time SW system, such as garbage-collection pauses or large variations in allocation times due to heap fragmentation, is then an undesirable complication. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .