Re: Share .cpp and .h along projects
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:5vkoc3hofoi6h0ibc66idv5dpdhr58v20e@4ax.com...
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.
You're right, I meant:
std::vector* volatile g_sharedVector;
Sorry about that. I thought you were challenging whether volatile was
needed at all, not where I'd put it.
[snip]
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.
If the visibility of x is sufficiently narrow (anonymous namespace) and its
address isn't taken, then the compiler can "prove" that the DLL won't use
it.
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.
Aliasing analysis still applies even when some functions are opaque.
--
Doug Harrison
Visual C++ MVP