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: geert@fozzie.sun3.iaf.nl (Geert Bosch) Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Date: 1996/11/26 Message-ID: <57dd70$1pf@fozzie.sun3.iaf.nl>#1/1 X-Deja-AN: 200829961 references: <325BC3B3.41C6@hso.link.com> organization: La Calandre Infortunee newsgroups: comp.lang.ada Date: 1996-11-26T00:00:00+00:00 List-Id: Kevin D. Heatwole (heatwole@his.com) 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? '' No, it isn't. The only problems relate to the priority requirements of Annex D. When you want to use ceiling priority locks, it is necessary to change and/or check priority of tasks which requires an expensive system call. As far as I'm concerned it is acceptable to have an implementation that locks a reference counter, updates the count and unlocks it without any priority checking, since the circumstances in which starvation of a higher priority task occurs, because a lower-priority task has the lock are very rare and the effects are much less disastrous then the erroneous behavior of reference counts without locks. Also, raising an exception in such cases is not too difficult to implement. The problems related to implementing a locking scheme with such very specific real-time behaviour as described by Annex D. should not be an excuse to use no locks at all. Regards, Geert -- E-Mail: geert@sun3.iaf.nl