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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Date: 1996/11/23 Message-ID: #1/1 X-Deja-AN: 198289722 references: <325BC3B3.41C6@hso.link.com> <1996Nov19.165503.24152@ocsystems.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-11-23T00:00:00+00:00 List-Id: Joel says "This discussion is related to Unbounded strings and someone's suggestion to use a reference-count finalization scheme and the possible problems with that with respect to tasking. The problem is that multiple tasks could all try to access the reference count at the same time, one decrementing and one incrementing for instance, right? So, to prevent that, some sort of locking would have to occur. However, we are talking about simply incrementing and/or decrementing 1 value in memory. On most processors that I can think of that is 3 operations, two memory accesses and an integer operation. Is the Ada tasking/priority method so accurate that that one lower priority task can't tie up the machine for 2 extra instructions? I think it ought to be able to handle even more than that. What about making an increment/decrement function that is a task or protected object at the very highest priotity level (higher than the highest as this is the compiler writer ... :) So essentially all reference counts are on the same lock. When a task wanted to adjust a reference count it would call / rendevous with the increment/decrementer which would take over and deal with the requested reference count. As long as that doesn't take too long and the call overhead isn't too large, no ones toes will be stepped on." The concern is not a semantic concern about taking the lock. As you point out, as long as the lock has proper ceiling priority semantics, this is consistent even with the strict semantic requirements of Annex D. The concern is that in an operating system environment, taking this lock may require a kernel call, and take thousands of instructions. This is not just a regrettable inefficiency, it is sufficiently inefficient that we could not consider using reference counts at all in this environment. Basically reference counts and tasking do not go well together, which is unfortunate, since reference counts are a powerful tool. Of course on an architecture like the x86, which has an indivisible decrement and increment that set the flags in a useful manner, you can implement them efficiently, but this is not true on all architectures.