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: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/11/05 Message-ID: <1996Nov5.083552.1@eisner>#1/1 X-Deja-AN: 194617648 x-nntp-posting-host: eisner.decus.org references: <325BC3B3.41C6@hso.link.com> x-nntp-posting-user: KILGALLEN x-trace: 847200957/18160 organization: LJK Software newsgroups: comp.lang.ada Date: 1996-11-05T00:00:00+00:00 List-Id: In article , eachus@spectre.mitre.org (Robert I. Eachus) writes: > In article <1996Nov4.072757.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes: > > > Running under an operating system on a uniprocessor there clearly > > must be a method of yielding to the lock-holder. In a preemptive > > scheduling environment this is automatic (although a yielding call > > is more polite). In a non-preemptive scheduling environment, > > a simple call to yield the processor should suffice, and that > > still leaves the overhead as approximately a memory read and > > test. > > Not to pick on Larry--or anyone participating in this > discussion--but I am really confused. Since all of the possible > modifications of Bounded_Strings must be done (legally) through a few > calls in the package, and Ada rules are really very clear in this > area, the Bounded_Strings package doesn't have to maintain any locks. > > It is the case that if you want to have a program which has > multiple tasks which reference the same bounded string, and one of > them does an update, then you have to have a synchronization point > before the next reference. I think the issue may be one of terminology clash. What Ada folk call a synchronization point may very well be implemented in what OS folk call a spinlock. I responded to what struck me as an OS-style discussion (I did not introduce the term spinlock to the thread) using OS-speak. Perhaps we should be talking about the overhead of a "synchronization point", but the original claim was that it can be cheap where there is no contention, so if nobody disagrees we can forget the term "spinlock" was ever mentioned :-) Larry