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,639dc0e939834477,start X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: pragma Shared (was Ada is almost ....) Date: 1996/02/17 Message-ID: #1/1 X-Deja-AN: 139888438 organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-02-17T00:00:00+00:00 List-Id: John McCabe says "I had another look at this today (even later than my last email to you) and I'm now convinced that the description in RM83 is based towards the compiler ensuring that it places some sort of mutual exclusion construct on these objects." Well you may be convinced, but you are mistaken! The idea is definitely NOT to generate some mutual exclusion junk. As with pragma Atomic in Ada 95, the idea is to restrict acceptance of types in these pragmas to those for which natural code generation ensures atomic access at the bus level (e.g. a 32 bit integer would be accepted on a 386, but not on a 286). pragma Atomic is QUITE different from pragma Volatile. pragma Atomic in Ada is essentially identical to pragma Shared in Ada 83. pragma Volatile in Ada is essentially identical to volatile in C, and is a feature that is not available in Aa 83. in general John, I strongly advise that you familiarize yourself with Ada 95, otherwise this conversation mostly retreads discussions that have been extensively carried out during the Ada 95 design, and in many cases the concerns you raise are obsolete, and no longer relevant from a language design point of view (although of course there will be some people still interested in Ada 83 workarounds).