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: jvl@ocsystems.com (Joel VanLaven) Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Date: 1996/11/19 Message-ID: <1996Nov19.165503.24152@ocsystems.com>#1/1 X-Deja-AN: 197466936 references: <325BC3B3.41C6@hso.link.com> organization: OC Systems, Inc. newsgroups: comp.lang.ada Date: 1996-11-19T00:00:00+00:00 List-Id: 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. On the issue of the RM and the implementation's responsibility I bring up the point that there are always trade-offs. Some users may not want to use tasking at all and want the fastest code possible. Some might want tasking and can handle less performance. The real responsibility of the implementation is to be explicit about what trade-offs were made. A suggestion is to provide multiple alternitives when feasible. Portability concerns suggest that implementations chose similar trade-offs, but I will leave that can of worms for another discussion. -- -- Joel VanLaven