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: "W. Wesley Groleau (Wes)" Subject: Re: Uninterruptible (atomic) operation? Date: 1996/12/11 Message-ID: <9612111939.AA14087@most>#1/1 X-Deja-AN: 203616956 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU mailer: Elm [revision: 70.85] newsgroups: comp.lang.ada Date: 1996-12-11T00:00:00+00:00 List-Id: > In article bobduff@world.std.com (Robert A Duff) > writes: > > > Pragma Atomic is essentially the same thing as Ada 83's pragma Shared. > > I don't think it's what you want in this case. > > Actually this is the case where pragma Shared or pragma Atomic can > be used, if supported for the object type. Wes just needs to lock the > value while it is being modified. The trick is to have a lock which > all the potential modifiers respect, and to use pragma Atomic, and > Atomic reads and writes, so that the readers can trust the value they > see. > > (Potential) Writer: > > Acquire(lock); > Temp := Atomic_Object; > -- operations on Temp... > Atomic_Object := Temp; > Release(lock); > > Reader: > > Temp := Atomic_Object; > -- use value in temp. 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." My (additional) problem is two-fold: 1. Typically, the hidden implementation of such is that a semaphore is used during both write or read to keep out other writers and readers. In the case of protected objects (which I can't use anyway, this is still true, except multiple readers are allowed). What I am trying to do, is find a way for the writer to disable preemption, so that readers are kept out even though the readers do not incur the overhead of the semaphore. That is, if the reader tries to read _during_the_write_ there will be a slight delay, but most of the time a read is as fast as any other variable. 2. An Ada 83 (which I'm stuck with) solution to (1) may not work if the reader and the writer are parts of independent Unix processes, and the shared object is created by system calls. At first, I thought of the solution where the item shared is a pointer to the object, and the writer could overwrite the pointer atomically, after non-atomically updating/creating a new object. Problem there is that the shared memory is guaranteed to be the same address for all processes using it. But if it contains a pointer, the object pointed to in process X may be at a virtual address that is used for something else by process Y. --------------------------------------------------------------------------- W. Wesley Groleau (Wes) Office: 219-429-4923 Hughes Defense Communications (MS 10-40) Home: 219-471-7206 Fort Wayne, IN 46808 (Unix): wwgrol@pseserv3.fw.hac.com ---------------------------------------------------------------------------