Re: shared memory between processes

From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 05/09/05 

Date: Mon, 9 May 2005 19:03:27 +0200

Todd Knarr <tknarr@silverglass.org> wrote:
> Conclusion: both interlocking via mutexes _and_ instruction to the
> compiler to always refer to the actual memory location are neccesary.

No mutexes are proved to be necessary by your evidence. Yes, you
need volatile (or anything else that causes reread on access). The
range of result values comes from reading registers, presumably.
The assembler will say.

The experiment did not seem very controlled to me. Can you please show:

 1) no mutex or volatile
 2) no mutex and yes, volatile
 3) no mutex and static, not volatile
 4) no mutex and static plus volatile.

At -O0, -O1 and -O2.

You can repeat with mutex if you like, but logically it is not
necessary since an integer read/write is atomic anyway. I don't believe
it would do anything one way or the other, except possibly make the
compiler treat the global as volatile under low optimizations.

> What bothers me about this whole conversation is that, the way I read
> it, people are claiming that, if a mutex protects memory location X, you
> can and should ignore the fact that the code may be referring to memory
> location Y _not_ protected by the mutexes.

?? I don't follow.

> It seems clear to me that,
> no matter what the Posix standard says about the mutex functions, you
> _can't_ simply ignore what the C and C++ standards say about the use
> of volatile as related to variables that may be asynchronously modified
> when you intend to asynchronously modify those variables.

Well, I still maintain that C says that it reads the value in a
variable when you ask it to! Not the value in a register that it may
have once used to hold the variable, and which now contains some other
value. I don't think volatile should be needed if you use -O0, and/or
tell the compiler not to use registers for globals (somehow).

Peter

Relevant Pages

  • Re: threads, signals, and atomicity of basic types
    ... some set of possible future C and C++ language standards. ... known to the compiler. ... memory location another thread of control also writes to or reads from ... In my opinion, the volatile ...
    (comp.unix.programmer)
  • Re: MSDN volatile sample
    ... volatile just slows down your code and confounds ... Conversely, if you use volatile instead of a mutex, your code is probably ... depending on the compiler and the machine architecture, ... anything atomic that isn't already atomic, and atomicity is frequently ...
    (microsoft.public.vc.language)
  • Re: Is gcc thread-unsafe?
    ... free to load and store to any memory location, ... This case is clearly a bug, ... volatile or that particular compiler version be unsupported. ... Marking volatile I think is out of the question. ...
    (Linux-Kernel)
  • Re: shared memory between processes
    ... > 3) no mutex and static, not volatile ... Look up what optimizers do with register caching. ... instead of the memory location. ...
    (comp.os.linux.development.system)
  • Re: Storing setjmp()s rv in a variable
    ... storing temporary results somewhere that setjmp() doesn't preserve. ... Assume a highly optimising compiler. ... memory location for x and rv, so a call to longjmp would overwrite ... declared volatile* is in danger of non-conformance. ...
    (comp.lang.c)