Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!uxc.cso.uiuc.edu!mcdurb!aglew
From: aglew@mcdurb.Urbana.Gould.COM
Newsgroups: comp.unix.questions
Subject: Re: Shared Libraries -- experiences etc
Message-ID: <59300005@mcdurb>
Date: 5 Feb 89 21:18:00 GMT
References: <81584@felix.UUCP>
Lines: 29
Nf-ID: #R:felix.UUCP:81584:mcdurb:59300005:000:1594
Nf-From: mcdurb.Urbana.Gould.COM!aglew    Feb  5 15:18:00 1989


>Most machines have an instruction called a "test and set" operation.  These
>instructions allow you to test the current value of a memory location and
>simultaneously (ie. non-interruptable) set a bit in that location. 

Beware. There are various degrees of "atomicity" in these so-called
"atomic" operations.

While nearly all of them are atomic wrt. interrupts on the processor
on which the instruction is executed, not all of them are atomic
wrt. bus traffic, and/or multiple processors on the bus, etc.

Usually these instructions work by asserting a LOCK signal at the external
interface of the (micro)processor. It is then up to the system designer to
decide what to do with this signal. I have seen systems where the lock signal
enforces atomicity only for certain of the set of instructions that
might possibly assert it; multiple bus systems where the lock is enforced
only on one bus, or in particular address ranges; systems where the lock
signal is asserted but requires the cooperation of all devices on the 
system to be meaningful (typically, distributed arbiter systems)
-- and, of course, the device that you need to talk to doesn't cooperate;
and systems where the lock is asserted and enforced, but where special
operations are needed to program around the behaviour of buffers, queues,
and caches.

In other words, take care to determine that the "atomic" instruction you are
using is indeed atomic with respect to the correct set of system features.
(There is an important notion of "relative atomicity" here; I wonder if
any academic has ever made such a notion formal?)