Re: Share .cpp and .h along projects
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:o9ibc35kas1d7r9j04a0httjq636u0js1t@4ax.com...
On Thu, 16 Aug 2007 16:30:28 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> 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.