Re: Share .cpp and .h along projects
On Mon, 27 Aug 2007 14:17:34 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
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.
As I said, "where you put it" was a MINOR part of the question. For
probably the 6th time at least, what do you think it ACCOMPLISHES in the
example you posted? That, of course, is the MAJOR part of the question. :)
I thought it was pretty clear, but if I need to be more specific, here
goes, "Explain, in your own words, what volatile does in your example, why
it's necessary, and what would happen if you were to remove it." Here, I'll
repeat your example for you ("corrected", so to speak):
std::vector* volatile 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);
}
What do you think volatile adds to your example? What do you think would
happen if you removed it altogether? Remember, this is an example of what
you asserted on 8/16, "any larger object can be controlled in a threadsafe
manner using a volatile pointer (which is word-sized) and memory barriers."
(As I did in my reply on 8/17, I again ask you to forget about memory
barriers, which don't apply to uniprocessor and x86 SMP.) What in the world
do you think "volatile" is doing for you here?
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.
Aliasing analysis still applies even when some functions are opaque.
Instead of repeating your assertions, can you provide even one example to
back them up? Here, I'll ask you again:
***** Excerpted from message I posted on 8/20/07
For all these reasons, I think I'm on pretty safe ground (to put it mildly)
when I say that volatile is not required when using synchronization. If you
still disagree, I ask you to produce a counter-example.
I think I'm on equally safe ground WRT what I've said about DLLs. If you
still disagree, I ask you to produce a counter-example.
******
If you choose to answer my questions this time, please do so in context by
replying to my post from 8/20/07, in which I asked them originally.
--
Doug Harrison
Visual C++ MVP