Xref: utzoo comp.lang.c:10467 comp.arch:5014
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!decvax!ima!johnl
From: johnl@ima.ISC.COM (John R. Levine)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: volatile (in comp.lang.c)
Message-ID: <1036@ima.ISC.COM>
Date: 28 May 88 19:03:06 GMT
References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <1988May23.003847.1114@utzoo.uucp> <21821@amdcad.AMD.COM>
Reply-To: johnl@ima.UUCP (John R. Levine)
Followup-To: comp.lang.c
Organization: Not much
Lines: 31

In article <21821@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>There is a perfectly respectable mutual exclusion technique which can be
>used on multi-processor machines, which requires no special hardware, and
>requires only that writes of a small integer are atomic. (The "small integer"
>has to be able to hold a processor number.) In the two-processor case, this
>is called "Dekker's Algorithm".  (For large numbers of processors, it is
>called "expensive"!  ;-}  ;-}  )
>
>The "volatile" type is necessary and sufficient for correctly implementing
>Dekker's Algorithm in "optimizing C".

Not so fast, there. In large multi-CPU systems, there is often a write-behind
cache and writes by one processor are not always visible to other processors
until you do some sort of cache-flush operation. (For example, on 370
architecture machines the cache is only flushed on process switch, start I/O,
and a very slow flush no-op.)

I can imagine that you might follow each write to a volatile variable with a
flush, but that would cause a huge and unnecessary performance penalty in the
common case that volatile is used to share data among asynchronous events on a
single processor, such as routines called via signal(), so compiler writers
would justifiably be reluctant to put flushes all over their object code. Then
you get compiler switches to explain to the compiler what you meant by
"volatile" or #pragma lines to say this is a single-cpu volatile and that is a
multi-cpu volatile. Perhaps this suggests that it's premature to standardize
the semantics of volatile, or even to include it in the standard language, but
that is beating a dead and increasingly smelly horse.
-- 
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
Rome fell, Babylon fell, Scarsdale will have its turn.  -G. B. Shaw