Re: shared memory between processes

From: David Schwartz (davids_at_webmaster.com)
Date: 05/07/05 

Date: Fri, 6 May 2005 15:31:01 -0700

"Todd Knarr" <tknarr@silverglass.org> wrote in message
news:BsRee.14673$tp.2627@fed1read04...

> In comp.os.linux.development.system <d5ghn2$c7m$1@nntp.webmaster.com>
> David Schwartz <davids@webmaster.com> wrote:

>> So you are saying that if a multi-threaded standard specifically said
>> that volatile was not required if you used mutexes, that standard would
>> be
>> incompatible with the C/C++ standard because the C/C++ standard
>> *requires*
>> volatile?! So, for example, I couldn't create a threading standard that
>> had
>> a new keyword, "volatile2" that did everything volatile did and more
>> because
>> according to you, volatile is required by the standard?

>> What you are saying is absolutely absurd.

> Not really. If you do _not_ specify volatile, what portion of the standard
> says the compiler is prohibited from caching it's value in a register and
> refering to the register, not the memory location (a common optimization)?
> And if, while the value is cached in a register in thread A, thread B
> modifies the memory location, how is A to decide it's cached copy is
> invalid?

    You are totally missing the entire point, which is really this simple.
The C/C++ standards do not mention multi-threading anywhere. So anyone who
is writing multi-threaded code is going to be doing so according to some
other document. *That* document will tell you how to stop *that* compiler
from making optimizations that interfere with multi-threaded code.

    Now, that document could hypothetically say that you should use
'volatile'. However, no actual such document that I know of does this. They
all specify other mechanisms that are guaranteed to be sufficient for this
purpose.

> Unless, of course, the mutex lock/unlock calls have special semantics in
> C/C++ to control what the optimizer does with variables not referenced in
> the calls. Which they may for specific compilers, but I've never seen the
> C/C++ standards mention this so I don't assume such semantics.

    If you don't know the semantics of the functions you are using to write
multi-threaded code, then it will be literally impossible for you to write
reliable multi-threaded code.

> Absent such
> semantics, I follow the C/C++ standard language that says volatile is
> needed on variables which may be modified asynchronously.

    Well, gee, that's pretty dumb. Rather than learn how to use the tools
you actually have, you'll just use things that neither necessary nor
sufficient to do the job you're trying to get them to do.

> Basically there are two problems:
> 1) Insuring atomicity of accesses to shared memory (this is where mutexes
> come in).
> 2) Insuring that the shared memory is actually what's accessed, not a
> register-cached copy created by the optimizer (this is where the
> volatile keyword comes in).

    And there could be dozens of other problems. For example, suppose
hypothetically we have a machine where not all memory is shared between
threads. (Nothing in the C/C++ standard says they must be, and you could
certainly write C/C++ code on such a platform.) Suppose that shared
variables really did have to be declared specially or they couldn't be
accessed at all, and a new keyword "shared" was offered to do this and
defined to do so by the relevant multi-threading standard. Suppose the
documentation also said that this "shared" keyword also prevented register
caching. Would you still say that the "volatile" keyword was necessary on
this platform?

    A platform could require a specific "flush" command to guarantee that
memory is visible on another CPU. Would you argue that every "volatile"
access had to be preceded and followed by such a "flush"? (And, of course,
you could *never* cite the part of the C/C++ standard that required that,
because the standard says nothing about memory visbility on other CPUs.)

    The problem is, your argument that "volatile" is necessary is not about
any particular platform. If it was about the C/C++ abstract machine, it
could apply to any C/C++ system, but it's not because the C/C++ abstract
machine has no concept of shared memory. So it isn't about *anything*.
Specifically, it is not about Linux/GCC.

    DS

Relevant Pages

  • Re: Volatile in C99
    ... I realize that's your opinion; ... Yes as it is your opinion not everyone's that an access to volatile ... referred to several different sections of the Standard, ... unknown side-effects may be. ...
    (comp.std.c)
  • Re: volatile vs aliased
    ... >> pragma Volatile; ... >> mentioned assembler instructions exist on a given processor) ... And in standard C++ the same for the builtin types and hence ... Of course (memory or other) reads and writes in the abstract machine ...
    (comp.lang.ada)
  • Re: How to halt a running program without losing data?
    ... > not available even in memory or register locations. ... Note that this is exactly the kind of thing that the VOLATILE attribute ... "useful" with it without stepping outside of the scope of the standard. ... it tells the compiler that things outside the scope of the ...
    (comp.lang.fortran)
  • Re: Volatile in C99
    ... written so as not to need volatile for such cases. ... but saying setjmpcan be used in a strictly conforming ... fact solely by the text of the standard, which is the reason I said ... the wording should be clarified. ...
    (comp.std.c)
  • Re: Volatile in C99
    ... written so as not to need volatile for such cases. ... but saying setjmpcan be used in a strictly conforming ... the wording should be clarified. ... it isn't clear what possibilities the Standard "provides". ...
    (comp.std.c)
Loading