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,2ef9ab4638027d85 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Uninterruptible (atomic) operation? Date: 1996/12/12 Message-ID: #1/1 X-Deja-AN: 204498295 references: <9612111939.AA14087@most> organization: New York University newsgroups: comp.lang.ada Date: 1996-12-12T00:00:00+00:00 List-Id: Wes asks "This is pretty close. But why do we need the lock? Isn't that implied by Atomic/Shared? LRM 83 9.11 (11) "each of direct reading and direct updating is implemented as an individual implementation."" Look at the code more carefully. The writer is depending on being able to do a series of operations on the value without any other writers getting in the way. The only thing that a reader needs is a guarantee of a consistent value. pragma Atomic or Shared should NOT use an implementation that involves a lock, implicit locks of this type are not at all in the spirit of what is intended. If you need a lock, you must use task syncrhonization primitives. the pragma is intended to identify cases where the hardware does an atomic load or store with no additional overhead. So, if the pragma is accepted, this approach does EXACTLY what you want. If the pragma is rejected, then there is no cheap way of doing what you want, particularly if you take the priority model of annex D seriously.