Re: Share .cpp and .h along projects


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

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.

That's nonsense, but simplify it to a uniprocessor system, which does not
have memory barriers. Heck, you could even limit it to x86 SMP systems.
Explain how you can use (say) a std::vector in a thread-safe way by "using
a volatile pointer".

volatile std::vector* g_sharedVector;

....

{
std::vector* pvector = NULL;

// this is a spin-wait, efficient on SMP, but on a single processor
system a yield should be inserted
while (pvector == NULL) {
pvector = InterlockedExchangePointerAcquire(&g_sharedVector, NULL);
}

// use pvector in any way desired

// with VC2005, can use "g_sharedVector = pvector;" instead
InterlockedExchangePointerRelease(&g_sharedVector, pvector);
}


Note that people who actually understand how to do multithreaded
programming and use synchronization objects such as mutexes rarely if ever
use volatile and may not even have heard of memory barriers, which they
don't need to know about in order to use synchronization objects.

They may not use volatile explicitly, but there aren't any
multiprocessor-capable synchronization objects that don't use volatile
interlocked primitives with memory barriers.


<snip>

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

Some of those optimizations cannot be safely applied by a compiler
intended
to be useful for multithreaded programming. For some reason, that point is
not getting across.

The compiler DOES apply those optimizations. If the code doesn't make
proper use of volatile and memory barriers to ensure that the correct data
is seen in other threads, then the code has a thread safety issue, not the
compiler.

Splitting functions into separate DLLs to prevent the optimizations is not
the right thing to do. It is fragile. For example, at one time simply
using two different compilation units within the same module would prevent
optimization. Now there is Link-Time Code Generation. Also, the .NET JIT
compiler does cross-assembly inlining and even native compilation can make
deductions and optimize across external calls using aliasing analysis.
Using "volatile" is the only way to make code robust in the face of
improving optimizing compilers, and as a bonus, it is part of the C++
standard.


.

Relevant Pages

  • Re: Substitute for volatile
    ... > I am a newbie w.r.t. compiler optimizations and I believe these ... "volatile" is a hint to the compiler that the contents of a variable may ... optimizations are at a function level, ...
    (comp.lang.c)
  • 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)
  • Re: MSDN volatile sample
    ... must be specified to get the memory barriers. ... Telling us we have to put volatile keyword to thread sharing data ... Now I strongly suspect whether compiler will generate any wrong code -- ... It seems that volatile will make wrong optimization to prevent thread1 ...
    (microsoft.public.vc.language)
  • Re: [OT] volatile in userspace
    ... Without 'volatile' and disabling optimizations altogether, ... 'Compiler over-optimisations and "volatile"'), volatile is used to ... Well, if you look at the Wiki, it admits that this is a bug: ...
    (Linux-Kernel)
  • Re: MSDN volatile sample
    ... Could you write down the code which is the *optimized* code by compiler ... will make thread1 deadlock without read the actual updated value of variable ... Telling us we have to put volatile keyword to thread ... To prevent optimizations, you specify a variable as volatile. ...
    (microsoft.public.vc.language)
Loading