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!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Mon, 07 May 2018 10:49:08 -0700 Organization: A noiseless patient Spider Message-ID: <87h8njmk4r.fsf@nightsong.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="8e10b317856a6344fb35132252789110"; logging-data="29000"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZPg8yAqCWdvzjmBq3BU4n" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:yBsQesCeGvcUVH6DAHPmK/UPtUU= sha1:A2IegRkdTTvSLFSviMPIug3Uobg= Xref: reader02.eternal-september.org comp.lang.ada:52069 Date: 2018-05-07T10:49:08-07:00 List-Id: "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. There are in fact realtime gc algorithms with guaranteed upper bounds on pause length, though they aren't used that often because conventional algorithms work well enough and have better overall performance. A non-realtime system won't notice a millisecond pause now and then, and a realtime system better not use refcounting either. Refcounting is also less efficient than gc because of the need to twiddle the refcounts all the time. That's especially expensive in multiprocessor systems since you have to protect every refcount operation with a lock. (C++ std::shared_ptr refcounts have such a lock and it's slow as heck) There has been more than a decade of pain in the Python community over this. CPython (the main implementation of Python) wraps a "Global interpreter lock" (GIL) around the whole interpreter, which means the threads of a multi-threaded Python program don't run in parallel even on multicore computers. The GIL can't be removed because the overhead of locking all the refcount operations would slow down the interpreter too much. And Python's refcount system can't be replaced by a GC because of the vast amount of C extensions that would have to be updated to no longer deal with the refcounts. Alternate Python implementations like IronPython and MicroPython do in fact use GC and it's much nicer that way. 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.