Re: Share .cpp and .h along projects
On Wed, 22 Aug 2007 11:50:42 +0200, Ulrich Eckhardt
<eckhardt@satorlaser.com> wrote:
Ben Voigt [C++ MVP] wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:nefcc3hh5er85j8hdrklli59i553ve10tu@4ax.com...
On Fri, 17 Aug 2007 15:14:50 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
volatile std::vector* g_sharedVector;
[...]
BTW, why _exactly_ did you use volatile in your declaration of
g_sharedVector? (Based on the declaration of
InterlockedExchangePointerAcquire, it shouldn't even compile.)
C'mon, it's an oversight coming from not consistently putting the
CV-qualifiers to the right of what they affect. I'm pretty sure you
understood what he meant and that he didn't actually compile the code.
Actually, I did try to compile the code, found I had to change the function
to InterlockedExchangePointer because InterlockedExchangePointerAcquire
wasn't available on my installation, and then discovered, to my surprise,
that it *did* compile. That's why I rather deliberately said "shouldn't
even compile". I figured we'd get to all that later, but so far, we've
gotten only to the need to use InterlockedExchangePointer.
Please note the fact that "it should not compile" is a minor part of the
question. I'm far more interested in what he thinks using volatile
accomplishes for his example.
Right, but it knows that lock and unlock are functions that affect
multithreading behaviour not only in that they lock a mutex but also that
they present a memory barrier (well, at least according to POSIX) and that
it must not cache the value of 'x' for that reason.
The VC++ compiler has no idea what those functions do. At least I can write
my own lock/unlock functions, put them in a DLL, and VC++ won't optimize
around them. Those functions can even be empty. Also, memory barriers are
not essential to the discussion.
Seriously,
multithreading is simply not possible without compiler support, it must
know that some code can be called in a multithreaded context.
I'd be interested to see an example that demonstrates what you're saying
that I can't reduce to "necessary for correct behavior of single-threaded
code".
Further, it knows that 'f1'/'f2' can be called by multiple threads at once,
so again it can't perform optimisations that affect 'x'.
As I remarked earlier, this isn't just an MT issue. It affects ST code as
well. The compiler does not "know" that f1/f2 may be called from multiple
threads. What allows them to be safely called from multiple threads is the
use of a mutex and the fact that the compiler doesn't optimize around the
opaque lock/unlock calls. However, the compiler doesn't "know" that you're
doing multithreaded programming; replace the mutex and lock/unlock with
renamed, do-nothing versions in an opaque DLL, and it'll produce the same
code. Get rid of them altogether, and the compiler won't continue to
"think" you're doing multithreaded programming; instead, it will perform
the optimizations previously inhibited.
Using DLLs to inhibit optimization is broken, Broken, BROKEN!
Thinking that multithreading problems can be fixed by inhibiting any
optimisations is broken.
Actually, the correct behavior falls out of inhibiting optimization around
opaque function calls. If the functions are not opaque, the compiler would
need some other way to determine the functions are unsafe to optimize
around. Because they are opaque, the compiler is unable to prove the things
it needs to prove in order to safely perform the optimization.
However, when a call goes into a DLL the compiler
must assume (as long as it can't inspect the content) that it could present
a memory barrier.
Memory barriers aren't essential to your argument; they don't exist on
single CPU systems or SMP x86 systems. What the compiler has to assume is
that an opaque function can affect "observable" behavior of the "abstract
machine". For my lock/unlock example, with lock/unlock in a DLL, it means
they can use the global variable x, so it must commit any modification of x
to memory before calling these functions, and when those functions return,
it must assume they modified x, so it will have to reload x from memory.
This is exactly what we need from the compiler for the POSIX memory
visibility guarantees concerning lock/unlock, thread creation, and so
forth, and it all falls out naturally when those functions are opaque.
--
Doug Harrison
Visual C++ MVP