Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: volatile isn't necessary, but it's there
Message-ID: <48767@sun.uucp>
Date: 7 Apr 88 22:43:59 GMT
References: <7794@alice.UUCP>
Sender: news@sun.uucp
Lines: 22

> The third hope for volatile, namely shared memory, is in some ways the
> most interesting because it nibbles at the edge of mechanisms
> that will become more important in the future.  Nevertheless,
> as several have pointed out, the Standard conspicuously avoids
> the extensions needed to make shared memory work
> (e.g. semaphores).  The dpANS even says, "what constitutes
> an access to an object that has volatile-qualified type is
> implementation-defined," and the sections that discuss
> what volatile actually does mean are correspondingly inexplicit.
> If you hope to find in the Standard that "extern volatile mutex; ++mutex"
> has an iron-clad meaning, you'll be disappointed.

It is worth noting, for example, that there is no guarantee that "++mutex" is
an atomic operation.  It is, in fact, worth noting that even if "extern
volatile char mutex;" was used, there would be no guarantee that "++mutex" is
atomic.  In all cases, for example, "++mutex" takes an instruction to load
"mutex" into a register, an instruction to increment it, and an instruction to
store it, on a SPARC.  The same would be true of any other architecture lacking
an instruction performing an "add 1 to memory" operation.

This is a real problem; there were some mildly entertaining bugs on Sun-4
caused by statements such as "++mutex;" in the kernel not being surrounded by
"spl" calls.