Re: Share .cpp and .h along projects


"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:p7r8c399sc57e5k24cj0t36qmn6ocpvc80@xxxxxxxxxx
On Thu, 16 Aug 2007 08:41:35 -0500, "Ben Voigt [C++ MVP]"
<rbv@xxxxxxxxxxxxx> wrote:

That is exactly what "volatile" does. Even in old versions of the
compiler,
when memory barriers are not used, volatile exactly prevents the
optimization you are speaking of, in a way that is not fragile to moving
source files between DLLs, changing optimization settings, etc.

Provided that "lock" and "unlock" trigger memory barriers, the code you
show
will be correct on any version of the C++ compiler (even non-Microsoft
compilers), using any optimization settings, if you would only say
"volatile
int x".

You can't require people to use volatile on top of synchronization.
Synchronization needs to be sufficient all by itself, and it is in any
compiler useful for multithreaded programming.

1. You're not thinking this through. Make x a vector<int>, and then what?
Cast volatile away so you can call its member functions? More generally,
how do you take existing code and use it in a thread-safe way?

Only single machine words can be used for interlocked operations, but any
larger object can be controlled in a threadsafe manner using a volatile
pointer (which is word-sized) and memory barriers.


2. Using volatile can be a huge performance killer, because it suppresses
optimization inside critical sections, where it's perfectly fine to use.

3. Reading and writing a volatile variable is ordered only WRT reading and
writing other volatile variables and other observable behavior, so what
you're proposing requires pretty much everything to be volatile.

"other observable behavior" covers a lot of things.


All you need is synchronization.

Synchronization is defined using volatile primitives.


In fact, if your "x" is in a anonymous namespace, which would be the
recommended practice, and you do not take its address, then the compiler
aliasing analysis can determine that it will not be touched by the
"opaque"
DLL, and reorder or remove the access to x once again.

That optimization is not safe for a compiler useful for multithreaded
programming. Note that I didn't say "touched" by the DLL; I said
"reachable" from the DLL. The difference is, the compiler would have to
prove no potential code path in a MT program accesses the variable, which
is quite a tall order.

Compiler optimizations (and CPU reorders) are always defined in terms of
equivalence on a single sequence of execution.


.

Relevant Pages

  • Re: i386 nmi_watchdog: Merge check_nmi_watchdog fixes from x86_64
    ... > after the store without volatile it seems a reasonable ... > as we have taken the address earlier so at some point the compiler ... pointer away and will be referring to it later. ... or if the compiler does whole-program optimization and can see ...
    (Linux-Kernel)
  • Re: Is there a way to flush registers and tell the C compiler to refill?
    ... Because using volatile would prevent some C compilation optimization, ... is nothing to worry about (other than a broken compiler). ... Such a caching ...
    (comp.lang.c)
  • Re: Is the following code MT-Safe?
    ... the assert (which is a fundamental design error: ... and almost always leads to either major synchronization failures ... >Does _bRunning need to be tagged as volatile? ... compiler to cache values, but only during the execution of a function; ...
    (microsoft.public.vc.mfc)
  • Re: Share .cpp and .h along projects
    ... optimization is a necessity for implementing mutex lock/unlock operations, ... correct compiler behavior for MT programming WRT these operations ... you use the volatile keyword for variables that are volatile. ... The mutex lock/unlock situation I've been talking about is illustrated by ...
    (microsoft.public.vc.language)
  • Re: Volatile + multithreading
    ... The volatile keyword has little use in multithreaded programming. ... > field or global seems to have no impact because it seems the compiler will ... operations as "special" and suppress optimizations around them. ... > majority of the multithreading issues that could have resulted from ...
    (microsoft.public.vc.language)